What framework are you talking about ? Symfony or Silex do exactly that : "respects the principles of abstraction that the programming language provides". Spring does that too. Any framework powered by dependency injection does that. Only frameworks that try to be to smart for their own good like Rails violate basic separation of concerns. Furthermore, just have a look at most Go or Node web apps out there : globals everywhere, tightly coupled code, no separation of concerns, no dependency injection,direct db calls in controllers... All because "you don't need a framework with Go" or "Dependency injection makes no sense in Javascript", good to luck to the people maintaining these messes 5 years down the road. Not using a framework doesn't make a automatically a codebase better. A framework however can mandate some discipline,especially when based on IoC : on one side : the framework's code , on the other side : the user code and the only glue is the manifest declaring dependencies between the two.

Speak for yourself. I am not guilty of any of these in my large node applications. And I use no frameworks, just npm libraries.

That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework.

I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability.

So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...

I would agree that it's almost always best to use a library where possible, preferably one that's widely used and very mature.

The author's point seems to be informed by being burned by many bad frameworks (which is, to be fair, 90% of frameworks - if you pick based upon fashion driven development this is the hole you'll end up in).

A good framework is rare but immensely valuable. A bad framework is worse than no framework at all.