Not to take anything away from Mike Hotek’s excellent book, but you will find that there are many controversial opinions and factual mistakes throughout. You can find the official errata here, which currently lists 10 items in the “Serious Technical Mistake” category.
It would be great if all technical books were error free from the start but unfortunately they are written typically by writers with some technical skills and then reviewed by a handful of technical folks for accuracy. Inevitably, some errors will sneak through.
In this age of everybody with access to publish just about anything, you will always want to keep a healthy bit of skepticism. In this particular case, you have the official product support teams blog in conflict with the “official” (but written by a third party) book. Not only is the blog to me a more reliable source, for this item, it matches what I have anecdotal observed in my own experience.
I believe that the confusion in the book comes from the fact that tempdb will appear to work differently from other databases and therefor we want to have more data files for tempdb than for other databases. The reason for this is that with tempdb you’ve got objects being created and dropped all the time (temp tables, table variables, internal objects, etc.) which creates contention on the GAM pages within the database files. By adding more physical files we add more GAM pages so that the allocations are spread out which will remove most or all of the blocking which happens against the GAM page writes. Typically tests show that 8 tempdb pages is enough for most systems (edge cases have needed hundreds of files).
People tend to push this same config setup to user databases as well, but the user databases don’t have this same problem as MOST (probably 99% or more) of user databases don’t do a lot of object creation. Multiple database files for user databases is great for spreading the load across multiple disk arrays.