It is important to say that nobody is advocating to “put everything in the same app, forever”. 
To me a great sign for splitting your Phoenix projects apart is exactly when you need to communicate to extra data sources, be it batch processing from CSV files or an API from a third party vendor.
Some have mentioned microservices in this conversation but what is being proposed, which is to split into multiple applications that depend on the same database, is against one of the core tenets of microservices/SOA which is operational isolation.
I understand some may still prefer to build their projects with multiple applications talking to the same database because it gives them more isolation at the application design level. But I also understand those who prefer to split things apart when you can actually guarantee they are fully decoupled. YMMV.
The only thing I am 100% sure is that if Phoenix generated multiple applications by default, we would be discussing how it is a terrible choice for most applications, how it is verbose, how it gives a false sense of security due to the operational coupling and how it is in general over-engineering. 
I am not saying I agree with any of those, just pointing out those discussions will happen regardless of choice.
That’s why I am glad we were able to grow Phoenix+Ecto to the point were all of those choices are possible. I like to say languages, frameworks and libraries should “enable rather than provide”. Languages more than frameworks, frameworks more than libraries.
And while we need to pick one approach for generators, the fact Phoenix just calls modules from the web layer, allows you to put your business logic anywhere: in the same app or different ones. And in there you can even get rid of the database altogether. It doesn’t care.
and a way to cater to the needs of the most common approaches to app development in Elixir… while at the same time allow you to spearhead what the community thinks is the smartest way to develop applications*. There could even be an 
