This was eerie to read. I've made some of the exact same points, word for word to others. It would be fascinating to do a survey/quiz for developers to see who's tempted to write tiny custom frameworks, and who knows better. This rant would also make a good first day read in an enterprise software engineering class.
Thinking over my career, I've seen a lot of libraries and tools out there that are really trying to be tiny frameworks. One example is [ngOptions](https://docs.angularjs.org/api/ng/directive/ngOptions) from angular 1. As a web developer, you're already using javascript, html and css at the very minimum. Yet ngOptions went ahead and created a new configuration language just for rendering a drop down. It was ok for simple stuff, but it rarely felt right for more complex widgets.
I think java bean mappers kind of fall into this trap as well. On the surface, bean mappers look like libraries. But once you start customizing the mappings, you see that each library has created a complex configuration language. The problem is that configuring custom mappings takes about the same amount of space as creating a tiny method to manage a specific field mapping. The difference is that I have to read a bunch of documentation to understand the bean mapper, but I already know how to write java.
At the end of the day, library vs framework boils down to imperative vs declarative. Libraries and imperative languages are composable and relatively easy to understand but can sometimes require a lot of work to accomplish difficult tasks. Frameworks and declarative languages require a lot of work to get right and are really only appropriate for problems that are well understood or formally described. They take on a tremendous amount of responsibility, but when done well they are incredibly valuable. There's a reason the world runs on SQL.