I don't think that schema or schemaless should change your app structure. Your entities/models should contain your data structures. If you structure your application right, schema doesn't matter. In fact, your persistence mechanism shouldn't either. Mongo, Mysql, Redis, they're just different ways to store and retrieve your data.
The biggest reason to avoid schemas is to avoid schema migrations. On big enough datasets, they take a long time. That is not every app's problem, so it depends on your app. Also, not having a schema doesn't mean you completely avoid data migrations as a result of changing your schema in all cases.
The problem with avoiding schema migrations is that you end up with those migrations in your code. If you add a new field or re-arrange your data structure, you have to add code to handle that old data. In many ways, it's simply easier (and less permanent) to do a migration.
I've done it both ways and I wouldn't go schema-less again. Right now I have decade old code in my models that handles old data structures that more than likely don't even exist anymore. With a schema I can just make the change and perform any data transformations in SQL and not be required to have any code to handle legacy data.
I agree that avoiding schema doesn't solve the problem. My point is that your schema exists in your code one way or another (explicitly or implicitly), and even without a database schema, you still need to either handle the schema differences in your code, or you need to migrate your data into the new schema in some way or another.
The best use of schema-less data storage I've heard of is Craigslist of MongoDB for their archives. Apparently migrations on their MySQL servers was taking way too long, and switching that system to Mongo made a lot of sense and apparently has worked out pretty well.
In the end it's about understanding the use of the right tool for the right job.
I have experienced slow migrations and it is a pain -- but it's not a fundamental conceptual problem -- it's just a tool problem. I believe postgres will or already has the ability to do background incremental schema changes without locking the table.
My point is that you have a schema in code and a schema in the database whether you have a fixed schema or an implicit schema based on the structure of your data. I prefer to be explicit.
The biggest reason to avoid schemas is to avoid schema migrations. On big enough datasets, they take a long time. That is not every app's problem, so it depends on your app. Also, not having a schema doesn't mean you completely avoid data migrations as a result of changing your schema in all cases.