The defaults of 8KB are based on experience with various browsers, http clients, (networking) hardware, proxies, etc ...
While it is possible to increase those values, you run a high risk of suddenly experiencing failures in your various clients to reach Jetty, let alone Jetty being in a position to even process the request. The failures can occur on the server side load balancer, intermediate networking hardware, transparent proxies on network providers, client side proxies, faults in client libraries, differences in client libraries, mobile networking differences, etc...
We generally only recommend increasing those values for environments where you control the entire chain (client -> network -> server) and can validate all pieces of the chain to ensure that it will work sanely.
There is also a number of vulnerabilities present in large HTTP headers related to Hashmap collisions which allow an arbitrarily small number of users and clients to DDOS the CPU and memory of the machine with relatively few requests. This is another reason the 8KB maximum has settle into common use across the industry.
As for memory calculations, there is no 1::1 relationship of memory use to connection count.
The memory comes from preallocated BufferPools and are reused as-needed.
It would be difficult to have all 10k connections each having a buffer of their own at the exact same time.
As for a calculation or a rule of thumb on how your memory will behave, that's impossible to prescribe without knowing your application and client access behavior intimately first.
