Hey Igor, if you take a look at http://pythonhosted.org/importd/#importd-and-custom-models, you will see that importd still works perfectly well with normal django app, and it is recommended when your project grow large that you indeed split your project into apps for maximum modularity and reusability.
importd makes it easy to start using django for simple couple of pages/api apps, and it remains compatible with rest of django, that is the goal.
Yup, I saw that on the first pass. So you have the ability to refactor, but you are basically guaranteeing that you will need to if your app grows beyond the couple of pages/api's size.
Additionally, there's another thing that importd side-steps: now there is no more settings.py. While I understand why, there is a reason for it to exist: configuration and code do not always mix. Sometimes you need a dev key and a prod key; sometimes you need different IP addresses set in different config files and you cannot autodiscover them (e.g.: they are not addresses from the same box). Having a better settings.py would go a long way towards solving this as compared to eliminating it altogether.
importd makes it easy to start using django for simple couple of pages/api apps, and it remains compatible with rest of django, that is the goal.