Regarding Question 1:
In general case — yes, it does. You don't know the details of a potential future attack so your job is to make an actual exploitation of any vulnerability as hard as it possible.
As you know, information security mission is to provide three values: confidentiality, integrity, and availability. Let's assume that a hacker gained a full copy of your DB (which affects confidentiality). Being able to log in as a user, he can take over integrity (by modifying user's data and performing actions on their's behalf) and availability (e.g. by changing email which can be used to regain access.
Before switching to question 2. As far as I know, MongoDB also has access control on a collection level, so it could help to limit attack propagation. You can also consider encrypting sensitive entries in a DB so unauthorized read-only access will won't be as critical.
Regarding Question 2:
There is no a right way because security decisions need to be done based on many factors which can be derived from risk-analysis. You can store user creds in a different DB or create a separate auth server, or use 3rd party auth services (OAuth).
The main goal here is to keep a balance between the price of implementing, supporting those security controls and a potential loss you might have in case of a data breach. My intuition is to keep it simple and follow basic security recommendation (like password hashing and access segregation using MongoDB access control tools) combined with other security controls of the system (like strict user input validation) you can find, for example, in OWASP ASVS checklist.