This is likely to be super confusing to new users; rumours that it's write safe and all the common examples will be fore the old driver...
IMHO they should have altered the defaults; people who require the extra performance will likely be the ones reading the changelogs / docs / these posts and notice.
Because, as they clearly explain in their rationale, that would break compatibility with all of the existing software out there that relies on the current semantics.
Thou Shalt Not Break Working Code is the first rule of building software that other software relies on.
They're deprecating but retaining the old driver to give people a transition period in which to modify their software instead of kicking them in the teeth immediately or forcing them to hold off on upgrading. That's the mature approach to fixing mistakes that people nonetheless built assumptions around.
That said, it makes sense for this to be opt-in behavior rather than the default.
At least in languages that support that feature (.NET, Java, C++ with some extensions).
A more aggressive approach, used e.g. in the CLR for really serious problems (like the improper HMAC calculation bug, or background threads not aborting in CLR < 2.0) give you a warning and allow you to switch it off via config, so no code change is required, but everyone gets the "fix".
Being a database doesn't mean you have to persist on disk. There is nothing wrong with in-memory databases. If you thought they were giving you persistence guarantees, then yeah, you would have a gripe.
I was then able to write a quick script to copy my mongo database over to elasticsearch. It was a joy.
The sheer amount of recent MongoDB hate has been extremely annoying, not to mention the half-assed reasons for justifying it - we've learned a lot of things from running MongoDB at scale, and none of them are what the haters usually whine about.
I think that MongoDB has got a lot of attention because its brand of NoSQL is one of the closest neighbours to RDBMS. I believe a lot of people may have dabbled with mongo and they might have walked away realizing that NoSQL is not 100% sugar plums and lollipops as evangelized. There are trade-offs between different NoSQL databases and RDBMS, and Mongo is no exception. Personally, I really like MongoDB and continue to use it.
Also, it's difficult to change something after defending it for a while. That's a promising sign.
My contention is that "safe" is a bad name for the parameter, and "async" is far better suited as it describes the semantics of the API.