It's not perfect (and there are both advantages and disadvantages to using a computer instead of a whiteboard) but when done correctly it gives a lot more useful insight than sitting there asking questions about their past the whole time.
Nobody is saying otherwise. The point isn't to make sure your thought process is identical to the interviewers (good interviewers will be more impressed if it isn't), it's to make sure you have one.
That may sound silly but read Jeff Atwood's thoughts on FizzBuzz[1] to realize how many "programmers can't program." Coding exercises are used to make sure you know how to think through a problem and solve it.
> I would estimate that recruiters would bias to hire candidates...
I'm not sure if you used the wrong word or not, but technical interviews are usually done by engineers or engineering managers, not recruiters. But yes, if I were interviewing somewhere and I sufficiently solved a problem but they didn't like it just because my thought process was different I would consider that a red flag.
[1] http://blog.codinghorror.com/why-cant-programmers-program/
I'll never forget how excited the lead dev was one day when he got some markers that would automatically make a digital file from whatever he drew on the white board.
I did not realize accelerometers/gyroscopes/whatever were capable of that.
I'm guessing you would find it sensible to hold auditions. Does an audition perfectly mimic what they would actually spend their time doing come showtime? No. There isn't an audience, the lighting and acoustics are different, nobody is wearing costumes, everyone is standing in the same place instead of moving around, people are reading from scripts instead of having lines memorized, etc.
The audition isn't intended to mirror a performance - it's intended to give some insight into how someone may perform. Likewise, whiteboarding isn't intended to replicate a typical day in the life of a software developer. It's intended to give a glimpse into how you solve problems.
As I said above, it's not perfect, but it's far more useful than hiring someone without any coding exercises and basing your decision just on how well they answer questions or what their background is. In fact the whole point of the post you're commenting on is to point out the foolishness of basing hiring decisions solely on having X years of experience in Y technology.
Whiteboarding vs no coding exercises is a false dichotomy. There are ways to test coding in a 45 minute interview that don't involve standing in front of a whiteboard, writing with a marker.
Sorry, it wasn't my intention to suggest those were the only two options (I was attempting to comment on the benefits of coding exercises, regardless of method).
Using a computer is certainly as good or better than a whiteboard. Though one of the bigger downsides to using a computer is there's generally this expectation you need to write "real" code that actually compiles and runs and so the focus becomes as much on writing syntactically correct code as about how you solve the problem (when only the latter has value).
The distinction matters. Are you an engineer or a tech? An architect or a laborer? Often, software developers end up being both (just as carpenters often end up designing and building). In particular, if you want your developers to be both, then you should make sure they can.
What you get isn't useful insight. It is the appearance of useful insight.