This is probably the chapter I have the most trouble with in practice. I get where he's coming from with not blindly accepting the opinions of people just because they are "senior" or your "elder". I can even accept the need to strike a balance and make tradeoffs between different aspects of the API design: beautiful APIs vs deprecations, correctness vs ease of use, simplicity vs variety/depth/breadth of use, performance vs premature optimization, backwards compatibility vs practical impact of incompatibilities, and symmetry vs other aspects like simplicity or potential to evolve.
It's the decision process in making tradeoffs and finding a balance that's hard to do in practice. That's where the "art" comes in and skill, experience, and aptitude really make a difference. In almost all aspects of the API design that he cited, I tend to start by favoring the former: beauty, simplicity, correctness, backwards compatibility, symmetry. The exception is performance. I'm a big believer of not optimizing prematurely so I take care of all the other aspects first. Seems like if you do that, performance very seldom needs much attention. And when it does, never forget that developers are notoriously bad at optimizing code based on gut feeling and intuition. Use a profiler!
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck