TL;DR -- allocation handling in Go and C# depend on a fat runtime library and the operating system.

I'm not quite sure of the author's point -- you took those dependencies when you chose those programming languages. Superficially framing how one micro-optimizes within those environments as "dependencies" doesn't yield any critical insights.

EDIT (more thoughts): A tangential example I can think of is how I worked at a C++ shop that "allowed lambdas if they weren't boxed" which was enforced by a build-step which inspected the generated assembly to ensure there were no instantiations of std::function. Perhaps a digression on how OP _validates_ their techniques avoid allocation, as opposed to "a human inferring it from reading source with rules-of-thumb" is a promising direction for a follow-up essay.