For a detailed explanation of what Django app's are and why they are structured the way they are please refer to the `2. Intro to Django Applications` section of https://medium.com/@djstein/modern-django-part-2-rest-apis-a...
For any new Django engineers reading this, I would point you towards https://github.com/pydanny/cookiecutter-django for the best / most complete structure.
The proposed design does compartmentalize business logic; it's all in the `domain` package, divided by business application/use-case. This looks to be to be inspired by the DDD approach.
> no ability to make new versions of an app and use them concurrently
Anecdotal, but I've never required this in my monolithic web app (6 developers), and I don't foresee requiring it any time soon.
> Removing the battle tested skeleton may mean it is not the web framework for your particular project.
This is a bit dogmatic for my taste; Django is just a tool. If the default layout works for you, great. When your project outgrows that default, change it. (But I'd advise being sure that you really have outgrown the defaults before doing so).