I believe even the language's own designers would agree with that sentiment. There's just generally a lot of things about Go that are great for low-level microservices but not great for 1M+ line of code business applications maintained by large teams.
I can't speak for others, but personally if I'm writing software with complex business logic, I'd want null safety, better error handling, a richer type system, easier testing/mocking... I've also never liked that a panic in one goroutine crashes the whole application (you can recover if it's your own code, sure, but not if it happened in a goroutine launched by some library).
I'd disagree with most of that, but the panic in goroutines really hits home. It's so annoying to remember implementing recover in every goroutine started to avoid crashing your application. I don't get why there's no global recover option that can recover from panic's in goroutines as well.
Goroutines are expected to communicate on channels. If one goroutine simply vanishes, then its counterparties on any channels will deadlock - either waiting for messages that never come, or trying to send messages to it after channel buffers fill up.
Crash is significantly easier to detect and understand than deadlock.
I can't speak for others, but personally if I'm writing software with complex business logic, I'd want null safety, better error handling, a richer type system, easier testing/mocking... I've also never liked that a panic in one goroutine crashes the whole application (you can recover if it's your own code, sure, but not if it happened in a goroutine launched by some library).