The C standard has those limits mostly because you cannot meaningfully define conformance without them.
Limits will be there whether you standardize minima for them or not.
For instance, no C compiler will handle a function with any number of parameters; as you try test cases with more and more parameters, eventually they will all crap out, right? If for no other reason, than memory.
So then if you don't have anything in the standard about this (like the ECMAScript standard doesn't, for instance) you have to conclude that all those compilers are nonconforming.
But if you have it in the standard that a conforming implementation must handle functions with 128 parameters, then those implementations which crap out at over 128 are spared from being declared nonconforming. Only those which crap out at 128 parameters or fewer have a conformance issue.
Limits settle questions. The user reads the spec and then has confidence they can have 4095 characters in a literal which will be portable to anything calling itself conforming. The implementor reads the spec and then has confidence that their implementation doesn't have to handle more than 4095 characters in a literal in order to handle maximally portable programs. There are goalposts firmly in the ground.
It can be useful for an implementation to optionally diagnose when a minimum limit is exceeded, even if it allows for much more. For instance, to tell the user they are using a larger character literal than 4095. This helps the user prepare a portable program that will work in other implementations.
Limits can work, but IIRC the original C would have set the limit on meaningful length of a variable name at 8 (or was it 6?). That... turned out to be a bad place to set that limit. So the limit had to be changed. But the more support the tooling gives for "preserving portability", the more support it gives for making it hard to change the limit when it needs to be changed.
The 6 limit was due to ancient linkers on Unix, which truncated external names to 6 characters. This affected file-scope identifiers with linkage (external or internal).
If a compiler has to work with some object file format which allows only six character symbol names (with case being indistict), there is nothing that can be done; but there is little reason to impose such a stringent limit if the underlying linker technology has a much more lenient one.
I think C90 still made that 6 character the minimum limit; a conforming C implementation of C90 was not required to accept a program which makes two external definitions that do not differ in the first six characters of the name, ignoring case.
In those days, it would have been useful to have a warning if you're using longer identifiers, or if your identifiers are not unique in the first N characters.
C99 raised a bunch of these limits, including that one; it became 31 characters. No mention is made that case is indistinct; it must be distinct.
The limit is still there; use 32 and your program is not strictly conforming to C99.
Limits will be there whether you standardize minima for them or not.
For instance, no C compiler will handle a function with any number of parameters; as you try test cases with more and more parameters, eventually they will all crap out, right? If for no other reason, than memory.
So then if you don't have anything in the standard about this (like the ECMAScript standard doesn't, for instance) you have to conclude that all those compilers are nonconforming.
But if you have it in the standard that a conforming implementation must handle functions with 128 parameters, then those implementations which crap out at over 128 are spared from being declared nonconforming. Only those which crap out at 128 parameters or fewer have a conformance issue.
Limits settle questions. The user reads the spec and then has confidence they can have 4095 characters in a literal which will be portable to anything calling itself conforming. The implementor reads the spec and then has confidence that their implementation doesn't have to handle more than 4095 characters in a literal in order to handle maximally portable programs. There are goalposts firmly in the ground.
It can be useful for an implementation to optionally diagnose when a minimum limit is exceeded, even if it allows for much more. For instance, to tell the user they are using a larger character literal than 4095. This helps the user prepare a portable program that will work in other implementations.