That's not true. There are several established and well supported libraries that actually work as expected. Then there are other, optimized versions of them.
The elephant in the room is the missing common build system, so folks engage in what's EASIEST - include just a header and you are done. This is awesome for initial development, gives you wings, but once your software has been deployed over and over - that header only library starts to show it's weakness - because it's header-only there are certain limitations - especially around how to handle singletons, initialization, and few other critical things.... And then compilation.
Some header-only libraries, realize that and simply asks the user to at least do this once somewhere:
and above gets code that needs to be compiled in exactly one compilation unit, and not multiple.
This is actually not so bad, if it was considered more... but it gets hairy when you have library that needs to use that header only library, and now up the tree of deps the top-most program has to do the above, and then it gets super messy.
Again, it's super easy, but not simple (long term). I've seen it happen with code that I work, I've also written tons of header-only libs - they are exciting!
