Both of the ways you are describing are pretty much the same thing with Team Foundation Server 2010. The In-Place Upgrade will automatically upgrade your actual database, as well. It will take a decent amount of time to upgrade the database, depending on how large it is. Make sure to plan that in your downtime estimations. If possible, replicate your server(s) to a VM that you can stand-up to take a test run at. It works wonders for your confidence, as well as helping to isolate problems before they happen on the production system.
The most important thing is that you back up everything prior to starting. Not that something will go wrong, but you want to be able to get back to square one, if needed. For an existing server, I would recommend ghosting the servers so that you have a quick and easy way to restore functionality in a limited amount of time.
As to the process itself - installing TFS 2010 is a dream compared to TFS 2008. One of the places the TFS team spent some time was improving not only the setup, but the initial configuration, of the server. I followed the directions from this post from the TFS team for the instance I have on my domain - although it was going from 2008 to 2010, not from 2005, as in the article.
In my upgrade experiences, I have run into no issues as of yet. Based on the "fun" had from installing TFS 2005 and TFS 2008, I was expecting it to continue to trend worse, but I was pleasantly surprised.