As of 2011, you will see the first drop in page performance after 14.6 KB has been sent. For the speediest page, all of your HTML code from the first byte up to and including the critical CSS should fit within this amount of data.
14.6 KB is the size of an HTTP server's initial TCP congestion window assuming a default TCP IW value of 10 (which was agreed on for major web browsers in RFC 6928). This 14.6KB payload represents how much data the server can send to the client before hearing acknowledgement that the data was received (aka before waiting for the first network round-trip).
If you think of the HTTP connection as a series of boat expeditions from the server to the client, 14.6 KB is when the first explorer's ship is full, and the rest of the HTML has to sit around and wait for the cargo ships.
So if the beginning of your HTML - up until the end of your critical inlined CSS - is less than 14.6 KB, that is optimal. Due to the way TCP congestion control works (doubling the amount of data sent as each burst is acknowledged), you can send 98 KB (14 KB + 28 KB + 56 KB) within 3 round-trips - so Google recommends that all above-the-fold content should be renderable with the first 98 KB of the document for mobile page speed reasons.
In short, 14.6 KB is the upper limit for critical inlined resources to fit within the first RTT. To fit within three RTTs and Google's recommendation, the cutoff is 98 KB.
This answer applies to HTTP/1.1 and HTTP/2, as they are both TCP-based protocols. This answer does not apply to HTTP/3, as it is a UDP-based protocol with its own inbuilt ramp-up strategy that I believe may be different than the strategy used by TCP.