A car plus an airplane has downsides in both car and airplane mode that cars and airplanes do not have.
I'm honestly wondering what the reasoning is behind the dislike of too many features, and how people justify the "right" amount of features. I can think of at least one argument against too many features, and that's managing what features a team should use in production, but there are solutions to that and I think that's a weak argument for the original assertion, which was entirely unsubstantiated.
I haven't used C++ or Java in over a decade, and I've never used Scala, so I don't have a horse in this race, but vague assertions deserve substantiation.
Languages like Go fall completely on the side of readable. I found that in my first few hours of Go, I could easily read through all the code that I found online and found it incredibly easy to reason about. But, as you'll hear time and again in critiques of the language, there's a lot of boilerplate that makes things explicit and many programmers dislike the lack of expressiveness.
Which brings me to Scala. Scala is on the entirely opposite end of the spectrum. When I first dove into Scala, I was constantly having to look up language constructs to understand the code that I was reading. And, worse yet, there was often no keyword or other indicator to tell me which feature was being used. In short, it was a nightmare to learn to read. But I'm sure the author loved it. S/he could express what s/he wanted from the computer in a few short lines that were entirely comprehensible to h[er|im].
My own personal view is that it's a right tool for the job situation. I think Go is a great language for large teams with high turnover. The fact that you could onboard a new Go developer and s/he would be able to read everything in your codebase and start contributing on day 1 is a huge plus. But if you've got a small, cohesive team that can agree on the subset of Scala features and overall patterns to use when developing, Scala could be a good choice since it would allow the team to move very quickly. There's a cost to both and it's important to consider when choosing a language. The main difference is that people too often evaluate the cost of a language based on their experience writing it rather than reading it.
I find programming languages follow the same rules, but often you are communicating with yourself (sometimes time shifted by minutes, hours or days). If you are an expert in a language that allows complex concepts to be defined concisely, you can use those idiomatic constructs to express your intent and another expert may easily grasp that intent, but a novice may find that much harder to comprehend. Conversely, a language that does not allow complex concepts to be expressed concisely will be easier for a novice to understand, but there is an inherent loss in efficiency for experts in that language that must resort to continuously defining complex concepts with the simpler concepts the language supports (boilerplate, in this case).
Neither type of language is inherently better than the other (as much as people like to assume so), they are just trade-offs that have different benefits and drawbacks based on the people or teams that use them. A team with low turnover and high experience could benefit greatly from the long-term use of a language that supports higher level concepts succinctly, while a a team with lower expertise or high turnover might find that extends the learning period of new hires. It's fairly easy to point out languages that have chosen one path over the other, such as Java and Haskell. I think an interesting case is Perl, which supports both, and I think that's a large source of the idea that Perl code is unreadable. It's made to be easy enough to understand in many cases at first glance, while also supporting a lot of higher level concepts. This can cause people that use it to experience very different levels of complexity in close proximity, which can be jarring for the novice, and sometimes the competent user as well.