The main technical reason is that most databases require you to authenticate in order to figure out which "schema" or "application" you are connecting to. Otherwise, it doesn't know who you are.
The main security reason is that connections from the local network should not be trusted. If another node on your network is compromised (a PC, a server, a wifi guest, the teenage sys-admin in the back room downloading warez), then so is your unauthenticated database. Of course your database and app server should reside behind a firewall either way.
You can limit the connections to localhost (same computer), but in many architectures, the app code runs on a different node from the database. If your app is co-resident with your DB, and you have a single dedicated DB for your app, then you can get away with this.
With databases that support schemas / multiple accounts, users are often dedicated to unique applications. MongoDB encourages this. This ensures multiple applications can safely share a single database infrastructure. I often host multiple web applications with a single physical database. App1 should not be able to freely connect to App2's data store.
Lastly, for auditing / compliance reasons, users must authenticate in order to identify who did what, retroactively. If you are in any business covered by regulatory controls, HIPAA, SOX, etc. accurate auditing is a requirement. Generic or shared users are not compliant.
As far as who is responsible? It is every programmer's responsibility, but especially the app programmer and database administrator. Often those are one and the same.
Maybe some of these don't apply to your app, but its a good practice nonetheless.