Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.
My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.
Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.
> Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams
I hate hearing this argument, because it glosses over the hard realities of building products, even if it sounds good on paper. Companies don't often have the resources to hire people that can do this early on, or the time to do this early on even if they do have the talent. And it might not be correct to do so when you have uncertain future requirements.
If that talent is you, you might not even be trusted to make those kinds of decisions until a year or two of tenure. And you might have junior (or even 'senior') devs on the side making changes that make this harder to do, without anyone realizing it.
So the reality is that you can't expect systems to be "architected properly" and you get what you get. It's an incremental process.
I have a personal experience that is literally the polar opposite of everything you just described. Atypical, yes, but on the other hand, testimonials about life in most other software teams describe an unnecessary mess of middle-management and bureaucratic cruft. I'm sure at many companies there are many roadblocks in the way between their developers and a better product, but my company doesn't have them. Not a startup, either. A 50-year-old engineering company that learned hard lessons after 20 years of stagnation.
I'm not going to be very sympathetic to counter-arguments about what "proper" practices we "should" follow, because quite frankly we're delivering features and value for our clients and catapulting back to the leadership position in our industry. Programming as a studied profession is barely half a century old, and the current zeitgeist of "best practice" is younger than some peoples' stints at the company they still work at. I'm very inclined to believe none of it is correct. No structural or architectural approach is one-size-fits-all and everything will be contingent on who you have and what you're trying to deliver.
Sure, its possible to be at one of those few great companies that are set apart from the others. If your company has a blog or videos that can share any of those insights I'd definitely be interested in learning more about how it was done.
My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.
Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.