That reads almost like a disparagement of GCC/Clang; the reality is you can just build on pretty much any host system directly and it will work. Having clean and repeatable builds is extremely useful, and Docker is a reasonable way to do that, but that shouldn't mask the importance of understanding the native runtime dependencies of the program once used outside of that one container. A concrete example of that: don't compile a C program in an Alpine Linux Docker image with dynamic linking, or it you won't be able to run the resultant binary on a RHEL machine. This is contrast to languages which run atop a virtual machine or interpreter, where the details of the build environment rarely matter on the runtime machine.
Its a disparagement at the fact they're dated, rather than the software itself.
GCC searches by default in /usr/include and friends, (and a similar set of paths for library paths), meaning that one random library you downloaded 11 years ago is now perpetually on your search path.
I write a decent amount of go, and it's not wildly useful there either but I still use them as the rest of the tooling is good enough that it works for me.
