I think the real reason for this stance is that it imposes a sense of discipline that wouldn't otherwise be there. When you write a library like this one, you're always tempted to overengineer it... maybe it needs to render .PDFs (or render to them)? Wouldn't it be nice if it supported various OS clipboards? How about supporting both OpenGL and DirectWhatever and that homebrew software renderer that you wrote a few years ago? And wow, it sucks to build complex interfaces by aggregating C function calls. Lua support would only take a few more KLOCs, right? ...

And before you know it, you're reinvented Qt. NTTAWWT, I guess, but if you set out to build a lightweight set of GUI controls for a specific purpose, you probably had a different goal in mind, and that's not the way to accomplish it.

In my own work I frequently include stb libraries in separate .c(pp) files that provide a somewhat higher-level C or C++ interface to the features I need, which are then linked in the traditional way with .obj files and minimal headers. This approach works well, maintaining encapsulation and keeping compile times down while avoiding dragging in a ton of random dependencies.