Splitting TempDB into multiples files equal to number of CPUs

A ratio of 1/4 to 1/2 times the number of TempDB data files to machine cores has long been the recommendation...

But there's now even better guidance. At PASS in 2011, my good friend Bob Ward, who’s the top guy in SQL Product Support, espoused a new formula: if you have less than 8 cores, use #files = #cores. If you have more than 8 cores, use 8 files and if you’re seeing in-memory contention, add 4 more files at a time. [link]

The last sentence has always been relevant. If you're not seeing contention, why add additional files? To play safe, most will add 2-4 files as a starting point for the majority of builds but beyond that, measure and react.

Like most general guidelines, it is a an oversimplification in its most positive light. At best, it is a good starting point (provided you don't aren't keeping the 1:1 core:data file ratio with a large amount of cores).

There is no replacement for proper design and proper follow-up monitoring and baselining. The reason behind having multiple data files for tempdb is to reduce and mitigate allocation page contention. There are numerous published posts on how to monitor this contention and take action accordingly. Below are a few resources:

Breaking Down TempDB Contention (Part 1)
Breaking Down TempDB Contention (Part 2)
Analyzing Tempdb Contention
Optimizing tempdb configuration with SQL Server 2012 Extended Events

But to answer your question, no this isn't a hard-and-fast configure-and-forget part of tempdb.