The purpose of a framework is to set constraints so that precious brain cycles aren't wasted on opinionated, (most of the time) irrelevant technical choices (and related training). So that, hopefully, the sum of the knowledge each dev in the team has of the framework covers enough solution space to solve all problems the team will come across.

> the only way to make a framework do what you want is an ugly way

Most of the time it gets ugly because the developer(s) doesn't know how to do that thing with that framework, not because the framework doesn't allow it, and would rather find an escape hatch than improve his knowledge of the framework and solve it the right way. I've seen this happen many times, both while studying and in a work environment. And if that wasn't the case it would be way more beneficial to tweak the existing framework and contribute upstream instead of creating "yet another framework" (obligatory xkcd: https://xkcd.com/927/), especially if you'd like to give back to the community.

Some frameworks have been around for decades (Django and Rails are good examples) and are still in active development, used by people in all sorts of industries, all over the planet. It's quite presumptuous to think your special use case hasn't been covered by at least hundreds of other developers, tens of which came up with what would probably be considered the right way to do that specific thing.

The only acceptable reasons for rolling out your own framework are: performance constraints that are imputable to the code architecture itself (hint: most of the time they are not), licensing issues, the lack of a framework for the language you're using and visibility (yes, releasing your own framework is a cool way of advertising your skills).