In any reasonably large organisation that is going to take you down one of two routes.

The first is that you end up with a defacto framework made up of the libraries that are useful in every project, with configuration copy and pasted from project to project. At some point you'll end up abstracting all that out into a higher level library, and boom, you're maintaining an internal framework.

The second, even less desirable, outcome is that every project in the company uses whatever mess of libraries the person who kicked off that project liked at the time. In that situation every time someone needs to work on a new project they lose hours to working out which libraries were being used, and learning how they fit together in this particular case.

In python you can use flask, in php you can use php. In both cases there are lots of common libs everyone will know how to use that can be included in the project, but not tied to a single framework. Once you remove templating, routing, orm and package management/directory structure from most frameworks you're not left with anything useful. So solve those problems at a library level. No framework required.

You've still created a defacto framework there by stating that your applications are built by integrating libraries a, b, and c in a particular way. You're also left actually maintaining that integration, and managing the entire stack for all applications using it.

Maybe that's a win for you and the extra flexibility is worth the effort, but that's probably not the case for most organisations.