One company I worked at had heavy SQL Server stored procs. I was pretty dismissive initially ("don't put business logic in the database layer!") but grew to understand that really those were the gold. The first versions were written in 1997 and by the time I arrived that code was bulletproof. There were about 4 UI technologies over 20+ years (VB, ASP, Forms + asp.net), but the procs were the same shape with thousands of edits for edge cases. Changing UX for the new hotness was massively de-risked and faster because the procs were solid.
Yeah, when I started in this field 20+ years ago, the wisdom I learned was that it was bad practise to tie yourself to the DB like that. But just like you I can see the value in doing it. SQL may be one of the most futureproof languages there are.
think around 2010 I worked for the one and only payment processor in my country. All ATM tx, POS, online were handled. The back office handling was done with Agile and Java. It was a pile of garbage. The frontend was still a massive mainframe. It had 10k+ COBOL program running it. With comment changelog on top from somewhere end of the 70s. The code review guy was doing this for 20 years and could tell if things would be slow and not scale all the Tx with just reading the code. Until today they never replaced it and is still running on it.
sometimes you don't need fancy new stuff. Just learn the things very well at your disposal. Heck sed, awk and bunch of simple cli tools still work well on Big data sets :)
CTO's change. They started replacing it with a "proper" ERP system around the time I left and it's been nearly 6 years of pain. Joel spaketh: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
(As usual: of course you can break the rule, but first deeply understand the risk you're taking.)