There can be problems with this approach, specifically, "The best way I know how" may not be the best way for the client. There are pros and cons with nearly every potential solution and it can be beneficial to discuss the pros and cons of more than one solution with the client before proceeding. It's arrogant to assume the best way you know how is the best way for the client.
For example, if you only know Ruby and the client is a PHP shop and you implement a solution for them in Ruby anyway, that could cause more problems than it is worth in the long run.
"It's arrogant to assume the best way you know how is the best way for the client."
That's not what he's saying. He's saying that he's going to try as hard as he can to come up with what he thinks is the best solution to the problem. It may not be the best, but it's the best he can come up with. It's better than someone who comes up with five options, then leaves it up to the client to make the wrong decision.
I just don't understand the aversion to expertise that's so common these days. Have some fucking pride in what you do well. And trust that other people know their shit, too.
It's not about pride in your work, it's about the reality of your client. Options normally intend to cover aspects and requirements of the work that the client didn't even think of. Options can allow you to create a solution better than the local maxima that you would find within the confines of your client's understanding of his needs.
I'm not arguing that providing options (done the right way) is a bad way to do it. I'm just disagreeing with someone who says the Paul Rand way of doing things is arrogant. Some people are extremely good at what they do. They have have tons of experience. They do extensive research. And in the end they're able to produce a single solution that endures for decades.
As your comment shows, "the best way you know how" when applied to yourself includes the realization that a PHP solution might be better for a PHP shop. Throw in another bunch of such realizations and a life long effort to actually come up with such realizations and you will understand why Paul Rand's approach is acceptable. He set out to solve Apple's problem. Not his initial and naive conception of their problem. He first made sure he understood their problem.
For example, if you only know Ruby and the client is a PHP shop and you implement a solution for them in Ruby anyway, that could cause more problems than it is worth in the long run.