The argument processing of db.coll.remove() seems to be modelled on db.coll.find(). However, the expected semantics of removal are substantially different to querying.

Semantically, the query parameter to find() is subtractive - as terms are added to the query, documents which don't have a matching form are elided from the set of documents returned. The query parameter is like a sieve, with an empty specification indicating no limitation on the form of documents to be returned. In the absence of any specification, defaulting to an "open sieve" and returning all documents is more likely to be useful than a "closed sieve" which returns nothing or throws an error.

However, I would argue that most users are used to remove/delete operations generally being semantically additive - only documents which match the query are added to the set of documents to be deleted. Given this, the default in the absence of a remove specification should be no documents, not all documents. Users expect this behavior because the highly destructive nature of removal/deletion means that conservative defaults are more prudent. The consequences of accidentally typing db.coll.find() are trivial, but the same cannot (currently) be said for db.coll.remove().

If users truly mean to remove all documents in a collection, it is not a significant imposition to require them to state this explicitly by running db.coll.remove({}). db.coll.remove() should not remove anything (nothing specified -> nothing removed).

The analogous behavior with Unix command line tools (which are notoriously unforgiving) is that /bin/ls defaults to *, but /bin/rm does not. If users actually want to delete all files in a directory, they have to do "rm *".