I think that some people misunderstand the primary purpose of Schema-less design. It's not about typing, it's about document flexibility. It's about getting rid of EAV tables (read: Magento) and storing document-specific information. Typing obviously comes into play, but is only half the topic.
If you are building a system where the schema is the same for all records, then you really shouldn't be using Schema-less design.
In a few projects I've worked on in the past year and a half, I've used EntityFramework C#, and added a Data NVarChar(MAX) field to each table.. then I added a base class that has a UseData(Action<JObject>) method that will pass a Json.Net based JObject in to be able to manipulate... adding additional properties that don't need to be indexed, and handling default values then becomes fairly easy with getters/setters. I also have a TempData table that is pretty basic where the core data is JObject based.
It's not the fastest option, but has worked pretty well for me. It did work out pretty well for holding temporary values, or other values that don't need to be indexed, or where the shape can change dramatically. I tend to store transaction details (credit-card, vs paypal, etc) in JObjects, since the shape can be different, with a key that can pull the right properties out via .ToObject<ConcreteInstance>()
In other cases, I've mirrored data to Mongo, so display versions of records can be pulled up denormalized from a single record/authority (the source records are across 30+ joins, and fairly expensive with a 50:1 view:edit ratio).
I will say that using MongoDB with NodeJS has to be the most seamless combination of tools I have ever worked with. I've written a few services based on this combination and love the development output. Fortunately my needs have been limited enough, that I have not hit too many walls. Most of the issues I have experienced relate to geo-indexes combined with other data, and the limits on multi-key indexes, and no secondary indexes.
I think more people need to consider how their data is shaped, and used and go from there.
If you are building a system where the schema is the same for all records, then you really shouldn't be using Schema-less design.