Isn’t that a step backwards? De linking them means you can scale the two appropriately independently.
I guess if you’re using could and can “steal” a bit of compute that way it makes sense.
It's definitely situational, and this can be true! But, generally its this kind of scaling optimization on everything that has us drowning in microservices today. If we can afford to "steal" some compute from the DB server, and minimize the amount of infra spun up for things that are basically scripts, I consider that a win.
Today there are lots of practical ways to autoscale databases and colocating data and compute is generally good for performance and simplicity (your mileage may vary for simplicity).
If Network I/O between your compute and data dominates every other dimension, you might want to to collocate compute and data.
Being able to fit the architecture to the performance of the workload is a good thing.
It could be for some use cases, but there are significant efficiency advantages to processing the data where it lies instead of shipping a copy to separate compute services.
Ideally you want scalable storage with compute (assuming really large datasets), so you can move the computation, which usually is small, close to the data.
In any case, it's not one size fits all, and each problem space matters.