I dislike frameworks for pretty similar reasons, but being a professional developer I can also see their value when you have to work as a team.

For example, with Ruby on Rails, you can jump from codebase to codebase and find your way reasonably quickly. Same with Laravel: I can open up a Laravel project, and immediately know what should be located roughly where.

From a DevOps perspective, they're also useful in that I can reuse the same template over and over to deploy these kinds of apps, because they use the same services in the same way.

I'd still rather not use one but then other people grow the project organically in all sorts of directions, and when it's the juniors, they get really lost and confused. I like to treat frameworks as semi-permanent training wheels. They're not for me, they're for the rest of my team.

i feel like all of these points also apply to code pilot results without any of the benefits.

I also feel like all of these points are important when evaluating a framework.

Yeah, everyone should just deal with assembly!
To be a bit more serious I agree that it'll be useful to be able to not need a framework, but also that frameworks do provide a great way to not need to duplicate as much effort. But a framework does make the whole project a bit more locked in to specific things it does easily and well.

In general I found the post to be fairly useful to have people read through to be knowledgeable about whether they need a framework and what things they might be giving up by using a specific one.