That's a little disingenuous. h2o isn't really a framework as much as it is a server that can be extended as an application (Similar to CherryPy vs Flask/Django). There aren't really any good C web frameworks, and any web applications built in C are very likely to be bespoke code utilizing some HTTP library (libhttp, h2o, kore, etc).
Actix is a framework, built in Rust and non-GC'd, that performs significantly better than any of the Go frameworks. So GC does seem to have some effect.
That being said, I agree the GC is unlikely to be the problem for D's performance (in this case).
It's not all clear that a garbage collector isn't an advantage in actual workloads. Web apps tend to create a lot of short lived objects, and contrary to popular assumption malloc and free are not free.
The alternative of gc is not malloc and free. It's custom memory management, i.e. the code that decides when to execute malloc and when to execute free. Even a gc will ultimately call the equivalent of malloc or free. The difference is gc needs to do it generic enough that it works for all possible programs; whereas a programmer needs to do it in a way it works for this particular program.
Actix is a framework, built in Rust and non-GC'd, that performs significantly better than any of the Go frameworks. So GC does seem to have some effect.
That being said, I agree the GC is unlikely to be the problem for D's performance (in this case).