I think this depends on specific project.
For example, if the different business domains are totally independent of each other, then I'd organize by business domain.
But if there is shared code between the business domains, or rather, the business domains are different variants of the same code base, then it seems more logical to organize by technical domain.
And if you use any sort of Object Oriented language, then you can probably subclass your generic controllers, models, etc in your business-specific files to make them thinner.
There is also a (golden) mid-way between the two - strip out shared code into it's own domain and use that in other domains. This gives you your gut feeling-powered layout, but allows shared code between business domains.
Domain1 # This domain changes bits of standard MVC code
Domain2 # this domain only modifies views, all else is standard
Shared # Here is the better part of code base
PS. I think that most frameworks organize by technical domain just because they tend to expect that you mix different business domains into single project only if you have shared code and otherwise would create separate projects.
For example, suppose there is a web app that handles a company's warehouse. In generic form this might apply to many companies, but each of them might have some specifics that aren't met and forbids them to buy in. E.g one of them has deployed tablets to the forklifts and needs special View for them while yet another wants to organize items into three levels instead of the default of two.
You could of course fork the project for each of these companies.
But if the framework/language allows, you could use subclassing or plugins etc to customize bits and pieces of the generic project to every customer's needs and organize them in the Business Domain layouts.
E.g if generic project exports to JSON only the Item itself, Domain1 can subclass the controller and make it export also recent delivery problems.
And if you later find that Domain1 has a component that is also valid for Domain2, you can extract generic version of it to Shared.
As you said, many frameworks organize by technical domain and that is what I have used for now, just because my FW of choice makes this easier. But with a little (or a lot) of elbow-grease, I think I could rewrite the include paths to support Business Domain layout too.