I can see where they're coming from, but as rules I would say these are way too specific for 100% restriction in a language design.
Gigantic 18+ layer convoluted inheritance schemes are pretty well-established as an anti-pattern for instance but inheriting 1-3 levels deep can be perfectly reasonable for solving certain problems depending on what other things a language design allows.
Likewise, it's fairly easy to see how method overloading could be done to excess, making an API so overwrought that you'd have to check the docs every time just to figure out how to use a method for the one of 16 ways you actually need it to work. Whereas, used responsibly, it's fairly easy to see how overloading for similar types in the same pattern could be completely reasonable and not at all difficult to remember. That, even more so than the inheritance thing strikes me as an odd feature to restrict wholesale. But, full-disclosure: I'm comfortable with a paradigm where everything is mutable, you don't have to declare a method twice to overload its arguments, and first class functions rain down from all over the place like candy from a busted-open pinata.
I would however argue that a general purpose language should probably be more flexible than Java is but that's not something 75% of Stack is likely to agree with me on necessarily.
Languages are inherently about design trade-offs. What this really comes down to is how sold you are on the philosophy in terms of solving the problems you typically need to solve. In this case, I think they're being silly for the vast majority of problems I've personally needed to solve but most of that is web UI stuff.