It’s not even clear that it broke their application. They simply didn’t allocate enough compute resources to it AFAICT.

"Broke" is commonly used to describe an interruption in application service to end users.

If one enables HTTP/2 and production goes down, someone could quite rightly point out that "you performed action A, causing impact B, which broke the app". Determining in root cause analysis that impact B stemmed from underprovisioned peak demand compute resources in no way contradicts the usage of "broke".

That’s not usually the way the term is used internally in practice when you exhaust your capacity, in my experience. It’s more typically used when sites start crashing or returning invalid data due to bugs in the software.

In my experience (adding 25 years of anecdata to the pile) running out of capacity which leads to interruptions in service to users will quickly get you a lot of emails about things being "broke" from both users and internal teams.

Internally, no. When dealing with incident response, you would not just say "http2 broke it", but as a quick way to describe the issue, it's fair to say "http2 broke our application" as it prevented access to the service.