Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework.
Also there are plenty of PHP codebases that were developed "organically" (i.e. without a framework) that are absolute eye sores to look at because without a structure in place its too easy for developers to write bad code.
Light and simple REST servers can be implemented quicker with Flask - less boilerplate and less setup.
Large complex codebases often have design considerations that don't fit neatly into Django's one-model-per-view, all-models-are-backed-by-a-relational-database opinions - think apps that require immutable datastores or frequent calls to an ML pipeline. Those are often better implemented as a composition of various libraries.
The thing about organic codebases is that, you can impose a better architecture if you so wish. Frameworks often make the architectural decision for you, in which case you're out of luck if that architecture doesn't suit your application.
I've worked with Django applications for years now, and this article definitely resonates with me. I think Python and other object-oriented languages have a bad time with composition, which is why overbearing frameworks rule the land.