Direct queries and ORM. A stored procedure doesn't provide much value as a unit of abstraction that couldn't just exist in the code.

If anything, it separates code from the data more as far as I can tell, so maybe I’m missing something?

Stored procedures are code -- so you're putting code in the database. How do you test that code? How do you source control that code? How do you roll back that code to the previous version or compare it to a previous version? How to know the history of that code? If that procedure is designed to work in together with application changes, how to test and deploy those together? This is all not impossible but it's certainly more difficult and creates more potential failure points.

Also, if something is somewhat data driven and there’s a bug, you simply alter a procedure versus doing a build and deploy of the entire application.

That's the problem. You write like that like it's an advantage but you're literally editing code live in production.

The performance advantages of stored procedures are unsupported. Most database engines do not treat stored procedures any differently than regular queries. And it's not that stored procedures aren't optimized, it's that queries are equally optimized.

Fortune 250 on down has used stored procedures with applications and it seems extremely clean and performance-oriented.

A lot of these companies also still use COBOL on mainframes (something I've actually worked on and don't recommend either). Stored procedures made a lot more sense historically when SQL might actually have more expressive power than your programming language and when database interfaces were much complicated and non-standard.

I use Windows 11 -- mildly modified -- StartAllBack for a proper start menu and taskbar experience. I have it pretty much exactly as I want it without any annoyances.

I'm perfectly comfortable with Linux but I feel the same as you about using it on the desktop for all the same reasons.

This my hot take: Do not use stored procedures with applications. Keep your data separate from your code.

In my family, everyone else has an iPhone and I have Samsung S23. So I can maybe give both perspectives. If you just want a phone to be a phone, it's hard to go wrong with an iPhone. It's always the best default choice. That being said, I personally can't go back to an iPhone. Lots of people recommend Google devices because of the "stock" Android experience but I greatly prefer the interface, integration, and customization of Samsung devices.

Anyway, in no particular order why I like Android/Samsung:

1. The ability to just copy movie and TV shows files onto the device and play them with VLC. This is a must for me for travel. iOS is still a pain in the ass for this.
2. In screen finger-print reader and face unlock (both are useful)
3. Ability to cast a Dex desktop to my TV with one click for showing off content
4. Customized gesture navigation (swipe up middle - home, swipe up right - back, swipe up left - apps) -- full screen is available no button bar
5. THE BACK BUTTON -- every time I use an iPhone I hate hate hate the lack of a back button
6. Browsers with ad block
7. Customized YouTube with ad blocking (revanced)
8. Customized notification icon bar -- hide icons that are always on (bluetooth, etc), battery percentage no icon.
9. Separate profile for Work and Personal -- my employer has control only of the work profile and can't remote wipe my entire phone.
10. Custom home screen apps (I use Nova 7)
11. USB-C -- one single charger for all my devices (phone, laptop, tablet, buds, etc).
12. Ability to wirelessly charge my watch and my ear buds using the back of the phone (this is great for travel)
13. Open source console emulators

I can probably think of more but that's a good start.