Note that the spec[1] requires that this tops at an implementation-defined size of integers, so you're likely not getting out of writing bignum code yourself (and even fifimplemented, the bignum operations may likely be variable-time and thus unsuitable for any kind of cryptography). Making the size completely implementation-defined also sounds like it'll be unreliable in practice, I feel like making it at least match the bit size of int would be a worthwhile trade-off between predictability for the programmer aiming for portability and simplicity of implementation.
Both Clang and gcc already support a 128bit integer type, so it's certainly possible that "implementation-defined" will end up being 128-bit or 256-bit for x64 targets on common compilers (provided MSVC plays along).
LLVM already supports completely arbitrary integer sizes up to 2^23-1 in its IR (https://llvm.org/docs/LangRef.html#integer-type), and I think it can “lower” any integer size to fit what the hardware actually supports. So if Clang doesn't add an artificial constraint on top, in theory you could use a one million-bit integer size if you wanted to?
Since I had to implement something like that in rust for a base32 codec [1] a few years ago I really like the idea. Although my main concern was ensuring that invariants are checked by the type system, which might not be as much a concern in c with its implicit conversions?
Judging by the motivation section, the motivation is primarily for FPGAs which I guess is why they want to allow these sub-int sized bit values. You might come up with some custom C-programmable operator that is only 3-bits wide where before you're presumably forced to use the smallest available power of 2 word size which would waste resources. So I think actually the idea is that this is for code which is not supposed to be portable at all, but rather hyper-optimised for custom devices.
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf