Objects don't solve this. Untyped programming is more flexible, but are able to express less things about the domain explicitly than typed languages (not Java/C#, but rather OCaml/Haskell etc.).
> if a static analysis tool were able to point to the same issues, the reason would evaporate.
This static analysis tool is called the type checker. The experience of using a type checker is best when the underlying language has sound types. Sorbet, TypeScript, Typed Racket etc. bolt a type system on top of an existing language, and so don't have a choice but to be unsound, and so their qualitative experience isn't as nice as it could be. Even so, they're highly recommended for large codebases.
> It's like saying a language is better because it has a better community, which is practical but not intrinsic
Not at all. This is an intrinsic feature of programming languages and has a huge effect on how we think of programs.
It is however not a silver bullet and when building web applications, practicality - tooling, ecosystem etc. trumps everything else. However if you run into difficult problems which require deep attention to data modelling, and wish for a better tool to help frame the problem, then Typed Functional Programming might be a good try.
