I always ignore this option when creating a new database on SQL Server 2005, simply because we can ignore something that we do not understand and leave it as it is. (I'm not so into DBA)
so now I am curious what it is about.
From your experience, when do you think we need to add secondary data files to my database and why do we need it?
Lots of cases where this can be useful - to start, for availability reasons it's always best to keep only system data in your primary data file (with Sql2k5 and up, so long as the primary data file is available, the database can be brought online, allowing you to repair/restore/etc. non-system data while having as much online as possible). Some other cases to use secondary file(s):
Besides the performance aspects already mentioned by the other replies here, there's also a safety issue.
The database's catalog views (that keep track of the tables, columns, permissions and all that system stuff) are always located in the primary data file and you can't change that.
If you can separate out that system catalog data in the primary data file, and put your user data into a secondary file, the primary file is smaller, gets a lot less updates and inserts, and thus the chance of corruption by e.g. a bad disk sector is minimized.
If your system catalog views (and their underlying tables) are damaged or destroyed, your entire database will be toast - so you definitely want to have the least chance of damaging that primary data file.
That's probably not a big issue in a smaller to medium size database, but might be a point to consider in a larger setup.
One of the big reasons is I/O. The ability to partition your data means that I/O is now spread across multiple drives/luns/etc. which can boost performance substantially.