Yes this is possibly why the author renamed the post. There certainly has been a problem of over-abstraction in the industry, with some of the most guilty parties being the frameworks (e.g. the infamous AbstractSingletonProxyFactoryBean from the Spring framework).
Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.
I think of frameworks as essentially higher order functions, e.g. map/reduce, where one provides the function parameters. That many frameworks seem much more complicated than this is certainly not a good thing.
