There has never been any CONTINUATION frame issues in the first place. Only a bunch of other implementations did it a strange way resulting in abnormal memory usage, but CONTINUATION frames are handled exactly how the spec meant them to be handled, i.e. concatenated on the fly as they are read. You can even try to send many frames of 1 byte if you want, there's no issue (aside the small overhead of parsing extra frames of course).

Regardless, given that it's being used and abused these days to waste server resources (CPU and network bandwidth in this case, memory for some other servers), they're now counted as glitches and you have an option to automatically close a connection above a certain number of glitches, and you can even track them in a stick-table that will allow you to block a source IP and share that info with all other LBs. I.e. the abuse of CONTINUATION (and all other classical H2 abuses since this one was known for 8+ years) can actually be used as a marker for a bad source that leads it to being blocked early.

There are other well-known attack vectors on H2, such as constantly sending SETTINGS frames to change the initial window size, whose cost can be proportional to the number of established streams, and, of course, the fast creation of streams that are immediately reset. All of this is properly counted as glitches and will be handled likewise.

I'm aware of a few large sites which managed to lower their CPU usage with this, by getting rid of this annoying background noise.

Also it's worth keeping in mind that when someone has enough resources to use your CPU this way, the impact would be roughly 100 times higher if they used the same bandwidth to force make you generate TLS handshakes! Thus, H2 attacks, while annoying, are a just a minor detail.