No, it is setting limitations, they're just harder to understand and predict. Here's what the RFC says:

  qvalue         = ( "0" [ "." 0*3DIGIT ] )
                 | ( "1" [ "." 0*3("0") ] )

(https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3....)

There are 1001 valid values with 1117 representations. Only in practice, Firefox clamps to 2 decimal places, and it used to clamp to 1 decimal place (https://bugzilla.mozilla.org/show_bug.cgi?id=672448), and who knows what other software does.

And it gets worse: the grandparent suggests there are servers that parse it as floating point. Do they accept q=1e2? If they accept it, are there clients that send it? Do you need to be compatible with those clients?

Based on the OP, this was the official parser for floats. That's a bit more extravagant of a bug.

I also would invite you to find a similar instance where a parsing bug for integers crashes the server. Not throws an exception, but falls over in an uncatchable way. I'm not sure I have ever seen one.

The issue is that the representation of floating point numbers imposes additional cognitive burden that the code must handle. How does the web server header parsing code handle positive/negative infinity? How about NaN?

NaNs/infs are particularly vicious, as they propagate through computations.

This. Floating point numbers, as they are lossy attempts to discretize continuous data, are more complex and usually non-deterministic. They should never be chosen when a non-lossy representation is available for the problem domain.

laughs in Ada

    -- IEEE754/64-bits: Interfaces.IEEE_Float_64
    -- And here we strip out non-numeric values.
    Use Interfaces;
    Subtype Numeric_Real is IEEE_Float_64 range IEEE_Float_64'Range;

Done.