I'd love it except for the databreach blame part. The DBA can't be held responsible for things like phishing, infrastructure attacks (Specture, etc), and other forms of stupidity beyond the DBA's control. For example, I went through a problem where someone got into our network and, somehow, figured out my 13 character password on the AD side of the house, and started dropping databases using my login, They determined that it got in by someone clicking on an O365 Outlook email (and I don't know how they figured that out). There's also this ransom-ware stuff and a whole bunch of things on the Windows side that DBAs shouldn't have to mess with nor be responsible for simply because it's all too big just for a DBA team to handle.
Shifting gears a bit, I will say that I was large and in charge of one application where I enforced users and the application having only PUBLIC privs and the privs to only execute stored procedures that I had personally reviewed. It was incredibly efficient and there were no performance issues. It wasn't because I was the person doing the enforcement and reviews of the stored procedures. It was because the folks I was working with actually understood how to write the stored procedures and why it was important. All I did was occasionally help the devs over a hurdle when writing the code and during reviews.
At the end, the Devs were pretty amazed at how quickly we were able to put together both front end code and backend code and how easy it was to make changes and corrections even with me being a review bottleneck because we ended up with nearly zero rework. A large part of our success was also because we formed a rock solid team that spent zero time bickering among ourselves.
And the penetration testing done by a third party flew with zero suggestions never mind faults. And, to be sure, we did have a "current user" variable for everything facing the front end and had other things within the stored procedures to track other sources of usage. It was pretty cool.
I was very fortunate to have the opportunity to do that once in my life. I very seriously doubt that opportunity will ever present itself ever again but that shouldn't stop people from trying to get there. The closer you can get to that, the better your application and database will be. You'll also be amazed at how fast you get the job done because you can approach the Nirvana of zero rework and rework typically takes a whole lot longer than just doing it right the first time.