Because the impact on your code by going with a serverless platform.
Generally speaking if it's the platform you have you will shoehorn the shape of your code into a serverless shape bucket even if it has no business looking like that.
These architectural shortcomings will inevitably come back to haunt you.
Also most of these platforms amount to cgi-bin v2, meaning things like memory leaks and requests that hang get swept under the rug.
Meaning you already have very difficult to diagnose failures and when you do eventually go to migrate you will find your code is full of these smells making it harder to reform into something reasonable.
That is also putting aside the spaghetti nature of intertwined functions of any serverless codebase of scale, the huge IaC overhead if you go with something like AWS Lambda and the massive amount of incidental complexity that serverless advocates try to make you look the other way for (hello API Gateway).
I'm not a fan of serverless/lambdas for this exact reason, I was referring specifically to PaaS solutions, where you can build your services without vendor lock-in, in a way that makes it easy to containerize later on. Things like memory leaks and requests that hang are usually reported by these platforms.
Fair, the ones that let you run containers directly like Cloud Run etc are fairly reasonable and approximate the k8s experience.
I think by going non-k8s you miss out on some of the key benefits though like standardized API and more portability of the surrounding infrastructure like networking and storage that is otherwise proprietary or not available on "simplifed" PaaS platforms.
I guess my argument boils down to cost of using managed k8s is low, low enough it's not worth using non-standard services instead.
Though I would like to address a point in your earlier comment though that is that it implied "k8s is about scale".
K8s has absolutely nothing to do with scale, the fact it can scale horizontally is a side effect of enforcing good separation of concerns and API design in the orchestration layer. You use k8s because the APIs make your applications better, even with they are small. This is the true innovation behind k8s. There were other platforms that made containers accessible (I worked on one called Flynn, Deis, Heroku to an extent, etc) but none of them pushed a better paradigm around orchestration which is why they didn't lead to the same level of success k8s has.
Generally speaking if it's the platform you have you will shoehorn the shape of your code into a serverless shape bucket even if it has no business looking like that. These architectural shortcomings will inevitably come back to haunt you.
Also most of these platforms amount to cgi-bin v2, meaning things like memory leaks and requests that hang get swept under the rug. Meaning you already have very difficult to diagnose failures and when you do eventually go to migrate you will find your code is full of these smells making it harder to reform into something reasonable.
That is also putting aside the spaghetti nature of intertwined functions of any serverless codebase of scale, the huge IaC overhead if you go with something like AWS Lambda and the massive amount of incidental complexity that serverless advocates try to make you look the other way for (hello API Gateway).