Using the right framework for the right reason is a productivity boost.
I agree. The difficulty with this is in the long term. Things change: new opportunities, new technologies, new developers, new functionality. Even if you were 100% certain of your choice on day one, it's difficult to measure the precise point beyond which your framework is no longer the "right" framework. I'm interested in solutions to this problem.
but doesn't this happen anyway? Business requirements change, technologies change, the tool that you chose 5 years ago is probably not the best tool for the job today, regardless of whether it's a framework, a library or another piece of software in your stack.
A possible solution is to keep your business logic framework agnostic, and write thin wrappers to plug into the framework where required. In theory it should be possible to change frameworks without incurring a major rewrite. This is easier said than done of course.
And when you do, the ones to blame are the programmers who wrote the app, not the framework.
> Frameworks in the most case feel like straightjackets
You mean "bad frameworks" feel like straightjackets.
Using the right framework for the right reason is a productivity boost.