Giving away information in the URL
An URL might be accessible even to a person that is not supposed to have access to the actual page it leads to. After all URLs can show up in links all over the web or leak via referer headers. Therefore there should be no sensitive information in the URL.
The Mongo ID contains information about the time the object was created (from the first part). The counter only contains information about in what order objects were created.
The counter also gives away information about how many objects there are in total (see the german tank problem). But so does the Mongo ID, since the last part is a global counter. It starts from a random number, so it conveys less information, but an attacker with lots of URLs can still estimate the total number of documents.
If URLs are sequential it is easy for an attacker to obtain a list of all resources. This is called an enumeration attack.
For the counter this is obviously easy to do. For the Mongo ID it is harder, since you have to guess at what millisecond objects were created. If you have a vague idea around what time objects are created, you could still brute force it.
If you are worried about giving away information about your documents in the URLs or letting users enumerate all documents both approaches are pretty bad. If you are not, both approaches are fine.
A third solution
If the issues above worry you, you could use a random ID instead. Use a large space to decrease the probability of collisions, and have some error handling so that things don't break if you are unlucky.
The ID could either be stored as the
_id (you can override the default) or in a field named
url_id or something like that. Put a unique hash index on it to make lookups fast.