Using database users in addition to the application-level authentication can be good defense-in-depth. I used this before, creating one database user for each user role as extra protection. It sounds like you will need application-level authentication anyway: how else will the application know whether to show administrative controls to different users?
If you would, instead, just show all controls to all users, and let the database deny executing certain actions to some users, that sounds like a configuration mistake waiting to happen.
It might also be tempting to let users run their own queries because the database should limit what they can access and modify. Having this type of code execution on the database system indeed increases the attack surface by a lot, as you identified. Various bugs in database servers are only accessible if you can execute a query to exploit it. Database connections (if users would get direct access) are also often not the safest, potentially only doing a protected login procedure but having no protection on the rest of the connection. There's a lot to consider when going down this path.
What would be interesting is to update the question with the DBA's argument(s). As it stands, hearing only your side, it sounds like the DBA is -obviously- a database person, where the database system is his/her hammer and authentication looks like a nail to them. Basically as wireghoul said: "[not] understanding who or what you are protecting against tends to result in ineffective security controls". This could be a concrete thing you can ask the DBA: what does their preferred method protect against that yours doesn't?