To dismiss the similarities is disingenuous.
I can't really answer to your argument because it is superficial and there isn't anything in there to answer to. Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away. Because it's easier to be handwavy than it is to construct a good argument.
Unfortunately handwavy arguments are subject to marketing and social forces. This is how people end up worshiping Python's spirit and included batteries, which must be some of the biggest lies in our industry, since I can name more non-orthogonal and half-baked features in Python than in Scala, plus several clusterfucks in its standard library and ecosystem, starting from the build management tools, the async-I/O libraries and the web libraries, all of them screaming anything else but "there is only one way to do it". But that's just the herd mentality in action.
Yes, Scala isn't exactly the C++ formula applied to java and functional programming; it doesn't, for example, strive for source compatability (C++ has to because of header files, it likely wouldn't otherwise).
Whenever I ask folks what makes Scala complex or bloated, or what the conflicting "styles of writing it" are there, they always shy away.
I don't think there's a good way to identify concrete examples for "bloatedness" because it's kind of a fundamentally handwavy concept. It's a feeling that you get while learning and using the language. One that people don't get with C, or Go, or Haskell or Scheme, but tend to get with Scala and C++ and Common Lisp, to name examples.
Complexity is easier to point to though. The interaction of inheritance and generics, the mutability semantics, the fact that it's not clear from the call site when arguments get evaluated (with defered evaluation and macros), anything that can result from an abuse of implicits, mutability semantics.
The various styles of writing Scala? Well there's the people who wanted to write Haskell but settled for Scala because it's what their bosses gave them, who write it with a lot of immutability and use the type system to a great extent. There's the people who wanted to write java but write Scala because their bosses make them, who write java in Scala because that's a totally viable way to do it. And there's a lot of people in the middle.
Addressing your python point: I agree that the "there's only one way to do it" mantra is kind of wrong in pythonland, but there are a lot of conventions in that community that people adhere to that make it true in a way. This comes with a lot of dogma unfortunately. Other languages have fewer "non-orthogonal and half-baked" features. Go, for all its issues, doesn't have many of those because it seems its designers are content to just not have the features at all rather than have them be imperfect. C doesn't either, really, nor Haskell.
I think Scala library authors would love some links to those things where you consider the documentation to be lacking.
C++ goal was that Bjarne didn't want to code ever again in plain C, after being forced to use it.
It just felt wrong to him such a primitive language after his experience with Simula and other proper languages of the day.
So when he joined AT&T, he started to work a way to have Simula for his work. Then the language grew from there.
There a few Bjarne interviews were he tells this.
I know the grammar is really difficult to parse and that has hindered static analyzers in the past, for example, but what else are you talking about? Also, how good or bad is clang's static analyzer compared to those of other languages?
I think
I believe that such claims are unwarranted,
mostly coming from beginners with a superficial
understanding of the language