As time goes on, I'm beginning to see some value in the whole "schema-less" concept. One use-case is for Proofs of Concept. Being able to rapidly create something and just mash whatever data you're collecting in a single blob in the database. That makes for quicker development (no need to map individual values to database columns) and yet it still gives you access to the data. Later on, the application could be changed to store it in columns, or perhaps it doesn't. Another app could be written to take that "blob" (JSON, etc.) and map it to another table with user-friendly columns, etc. for such things as reporting.
The old adage of "if I have a hammer, everything looks like a nail" seems to hold true here. If I know (and love) SQL Server and its relational-concepts, I tend to want to force everything into that paradigm, but it's good to understand and explore other options. ... Not everything is a nail! 😉
Except that there's that other problem where the prototype becomes the real thing and you get lumbered with a load of technical debt.
Using a relational database is not really a hammer. Your comments main assertion is to save time not because things don't fit into relational concepts.
My problem with conference vids I've seen on this topic is that as soon as you need reporting they completely fall apart and become more of a burden then just doing relational SQL in the first place.