I think the real appeal of "schema-less" (actually, it should probably be called "ad-hoc schema" since nothing is schema-less) is that new "table structures" can be defined without regard to existing ones. My hobbies usually involve the need for LOTS of data storage and I once tried to create a database for D&D world creation. This meant I needed *thousands* of tables, one per different kind of object (planets, countries, skills, spells, creatures, you name it...).
I used Access (which is a relational DBMS regardless of what detractors would have you believe) and the result was a set of half a dozen tables to handle "ad hoc" tables. These tables contained the details of the "tables". The user could create new tables (actually, object blueprints) to their hearts' content, and export them to other users (both "schema" and data). It worked very, very well for what it was intended for.
In short it was almost identical to the way SQL Server works!
SQL Server does EXACTLY the same thing, in a far more sophisticated way. Every time you create a table it goes in a system table. Ditto for columns, indexes, permissions, etc.
So in effect a no-SQL database does exactly what a SQL database does, just less efficiently and in a less granular fashion. Developers think this is easier, and then spend all their time replicating features SQL Server provides for almost free.
It's really no different than building every table with NVARCHAR(MAX) columns for everything, in other words they're a bit ignorant of helpful features.
I suspect there ARE use cases where no-SQL is a better fit. Maybe important ones (Google indexing comes to mind, or YouTube).
But IMO the vast majority of cases are better off with structured schema, be it SQL or something similar.