This probably matters a lot less than younger people think. If you grew up touch-typing you got used to being able to put data in as fast (or almost as fast) as you could think it. If the input rate is slowed down, you feel like you're going to lose thoughts before they get captured.
Folks who did not grow up touch typing, though, simply learned to construct a longer-lasting mental model, which they can then write out however slowly. Think of it as a bigger buffer. In rare cases it can become enormous, and people write entire novels in their head before ever putting ink on paper (famous example: "The Diving Bell and the Butterfly", which was written at a rate of about one word every 2 minutes).
Or, they learned to create and capture design decisions in higher-density media (like diagrams or pseudocode), which, again, can then be typed in more slowly.
It's probably much better to judge developers by the quality of their output than how fast they type--especially since most software spends way longer in production and maintenance than it does being developed.
Having a slow typing speed still means that one spends a lot of time typing, rather than doing other things, even if one can still accomplish the same mental processes without having to record it "live".
Do you really type at full speed all the time though? Most of my time is spent thinking, and when I do type something it tends to get pipelined with more thinking. Typing faster wouldn't help much.
In fact, I'd wager that if someone is typing constantly at 100+ wpm they're probably writing bad code. Or very simple code, I guess. Or they're just transcribing UML or whatever, but nobody here does that anymore do they?
How many lines of code per day do you actually write? 10? 100? 1000?
If we assume something like 30 characters per line, and maybe five characters to a word, you'd be writing 600 "words" in a day where you'd write 100 lines, and as many as 6000 "words" in a 1000 loc day.
100 wpm for 600 words means you're saving 6 minutes per day over the 50 wpm guy. Not much, I doubt anyone would care about 6 mins one way or the other. 100 wpm for 6000 words means you're saving an hour over the 50 wpm guy. It's rare you write 1000 loc. I don't know if I've ever done it, myself.
But that's just code. How often do you write non-code related work? Documentation, email, notes, comments, spec, etc. 6000 words per day is probably not uncommon for a developer when you include the noncode writing a dev will do during a day, and when a 100 wpm guy gets done a whole hour before the 50 wpm guy, that's an undeniable advantage.
If you have two candidates who you're certain are equally good developers, then obviously the one who types faster will be more marginally more productive. But I wouldn't assume typing speed or style is an accurate proxy for programming ability.
I think it's rather a proxy of how long the person spends writing on a computer. For a programmer more time spent writing generally means more time programming, which means more experience.
I don't think time gains because of faster typing don't even factor into a decision, but broader knowledge/experience does.
Folks who did not grow up touch typing, though, simply learned to construct a longer-lasting mental model, which they can then write out however slowly. Think of it as a bigger buffer. In rare cases it can become enormous, and people write entire novels in their head before ever putting ink on paper (famous example: "The Diving Bell and the Butterfly", which was written at a rate of about one word every 2 minutes).
Or, they learned to create and capture design decisions in higher-density media (like diagrams or pseudocode), which, again, can then be typed in more slowly.
It's probably much better to judge developers by the quality of their output than how fast they type--especially since most software spends way longer in production and maintenance than it does being developed.