Application code in stored procedures? Is this still a thing? SQL2003 standard was completely into it with Java as stored procedures and XML, etc. - but wasn't that just an enterprise fade with big expensive enterprise databases like Orcale/DB2/MSSQL?
It introduces a lot of headache if you update your code often - it's already hard enough with schema changes, especially if you would like to be able to roll back faulty updates. Normal code is maintained a source code repository (GIT/SVN), it can be edited, diffed and debugged using a common IDE.
In what way aren't stored procedures "normal code"? Are you claiming Git can't handle SQL files? Or that they can't be tested? Or there are no debuggers or IDEs?
Here's a clue, a serious project will go through a dozen languages before it changes its database. You can reimplement your business logic that many times, or do it once, properly.
What I tried to point out it complicates the schema-update step a lot. Lot's code as stored procedures was counter productive at least in my experience. Several blog posts (post mortems) mention they avoid stored procedures as much as possible. I would debate that a "serious project" changes the code language at all. Even the old rusty SAP only switched from ASM to C and ABAP and reverted their Java misadventure. And Microsoft's products are still 90+% ASM, C and C++ code
Still, stored routines in a cloud DB might be more interesting than a full blown middle tier.
The biggest problem with cloud DBs I find actually isn't so much their architecture, but rather the fuzzy rules around charging access to them.