This should be the top comment.

TL;DR: HTTP/2 is internally concurrent, can handle multiple streams. It is possible in HTTP/2 to send a nasty request that looks like so:

  - GET x1
  - GET x2
  - GET x3
  - ...
  - GET x100
  - Actually, cancel all of the above (uses multiple RST_STREAM frames)
  - GET x101
  - GET x102
  - (...)
  - GET x200
  - Actually, cancel all of the above (uses multiple RST_STREAM frames)
  - (...)

This can be repeated a lot of times. The problem is that the endpoint, which typically is a reverse proxy, might start dispatching the requests before it reads about their cancellation. And sure it will cancel them, but by the time of cancellation it will already have resulted in some resource usage downstream. Such requests are accepted because at no point the client has opened more than 100 streams, which is the typical concurrency limit. The example from the blog manages to squeze in a single packet 1000 GETs (i.e. 1000 HEADERS) correctly interleaved with RST_STREAM.

Maybe it's just me, but it's always fun to see such creative and simple abuses of protocols/code.