Normally I hate the word, "premature optimization", but this reeks of it. It's worth noting that Knuth used this famous quote in the context of pushing to use
goto statements in order to speed up code in critical areas. That's the key: critical paths.
He was suggesting to use
goto for speeding up code but warning against those programmers who would want to do these types of things based on hunches and superstitions for code that isn't even critical.
switch statements as much as possible uniformly throughout a codebase (whether or not any heavy load is handled) is the classic example of what Knuth calls the "penny-wise and pound-foolish" programmer who spends all day struggling to maintain their "optimized" code which turned into a debugging nightmare as a result of trying to save pennies over pounds. Such code is rarely maintainable let alone even efficient in the first place.
Is he right?
He is correct from the very basic efficiency perspective. No compiler to my knowledge can optimize polymorphic code involving objects and dynamic dispatch better than a switch statement. You'll never end up with a LUT or jump table to inlined code from polymorphic code, since such code tends to serve as an optimizer barrier for the compiler (it won't know which function to call until the time at which the dynamic dispatch occurs).
It's more useful not to think of this cost in terms of jump tables but more in terms of the optimization barrier. For polymorphism, calling
Base.method() doesn't allow the compiler to know which function will actually end up being called if
method is virtual, not sealed, and can be overridden. Since it doesn't know which function is actually going to be called in advance, it can't optimize away the function call and utilize more information in making optimization decisions, since it doesn't actually know which function is going to be called at the time the code is being compiled.
Optimizers are at their best when they can peer into a function call and make optimizations that either completely flatten the caller and callee, or at least optimize the caller to most efficiently work with the callee. They can't do that if they don't know which function is actually going to be called in advance.
Is he just talking out his ass?
Using this cost, which often amounts to pennies, to justify turning this into a coding standard applied uniformly is generally very foolish, especially for places that have an extensibility need. That's the main thing you want to watch out for with genuine premature optimizers: they want to turn minor performance concerns into coding standards applied uniformly throughout a codebase with no regard for maintainability whatsoever.
I take a little offense to the "old C hacker" quote used in the accepted answer though, since I'm one of those. Not everyone who has been coding for decades starting from very limited hardware has turned into a premature optimizer. Yet I've encountered and worked with those too. But those types never measure things like branch misprediction or cache misses, they think they know better, and base their notions of inefficiency in a complex production codebase based on superstitions which don't hold true today and sometimes never held true. People who have genuinely worked in performance-critical fields often understand that effective optimization is effective prioritization, and trying to generalize a maintainability-degrading coding standard out to save pennies is very ineffective prioritization.
Pennies are important when you have a cheap function that doesn't do so much work which is called a billion times in a very tight, performance-critical loop. In that case, we end up saving 10 million dollars. It's not worth shaving pennies when you have a function called two times for which the body alone costs thousands of dollars. It's not wise to spend your time haggling over pennies during the purchase of a car. It is worth haggling over pennies if you are purchasing a million cans of soda from a manufacturer. The key to effective optimization is to understand these costs in their proper context. Someone who tries to save pennies on every single purchase and suggests that everyone else tries to haggle over pennies no matter what they're purchasing isn't a skilled optimizer.