Tweaked proposal:

Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that an intermediary can be assured of buffering the entire response. Additionally, very large chunk sizes may cause overflows or loss of precision if their values are not represented accurately in a receiving implementation. This may have serious security consequences.

WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"

I think if we say something about that, we should align it with the language for Content-Length:

Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of content, a recipient must anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows

OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say and prevent parsing errors due to integer conversion overflows or precision loss due to integer representation. We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!