Possibly. However, tooling and code generation can help.
If the smarts is just a state machine, and the rules are abstracted at the right level, it would not be that hard to support.
"Thick" smartpoints can save on operating cost (infrastructure, personnel, complexity, level of expertise) when your system is "simple enough"
At massive scale, from an economies of scale (all things considered), it may make better sense to go with "Thin" smart endpoints.
The migration between the 2 models is where the art of the design comes in play :) It's an art because it is a decision process involving many players with conflicting and competing goals, decisions, time frames, motivations etc.
Actually, I didn't like the sidecar idea at first, given my experience with it ten years ago (we ended up changing architectures twice). But that was in a project where everything was in the language (C++) that was best supported by all the internal libraries.
I've since been exposed to the vagaries of dealing with multiple languages. I think code generation can only help so much, if you care about performance and latency. Things like flow control and handling memory pressure are easier in some languages vs. others.
Not going very far, if you look at gRPC, it really has three implementations: C++, Java and Go. All other supported languages wrap the first. They have different defaults, feature sets and performance characteristics. Not to mention the behavior under load. In theory it shouldn't be like that.
