Yup, hence "used to", but I could be clearer it's no longer an issue.

My issue with your statement is that you're pretending that this was a recent issue. This hasn't been an issue in over half a decade. Do we point out bugs in libraries from 6 years ago? Are we critical about what other languages looked like then? In my experience, Java is the only one that gets this criticism.

still need it for class members, unlike in some other languages.

Most languages don’t do type inference in “signatures” (function, but also class/struct members), as it would give you negligible benefit, a huge cost for the compiler and is commonly thought of as a bad practice.

Out of Scala, Rust, I believe even Kotlin, none do inference in these places. Even Haskell, which does infer function signatures as well, need explicit type annotation for `data` definitions.

typescript does such inference.

I disagree with you about huge cost for the compiler and benefits are the same as in normal code block: reducing boilerplate.

Typescript’s type system is deliberately not sound though.

In general, there is no type inference available for OOP type-hierarchies as opposed to a more Haskell-like type system, where Hindley-Milner works

I don't have strong knowledge in types theory, but why

class C { a: int = 0; }

can't be replaced with

class C { a = 0; }

? what issues it brings?..

That can. But what about a field that is not initialized there?

obviously you would need to provide type.