In an ideal world each new install would be on a nice shiny new server but in the real world it depends entirely on your setup, application, clients and timeframe for the upgrade. With the right planning and research, an in place upgrade can be a perfectly sensible option. The key for whichever method you choose is always having a rollback plan.
Whether you're moving or upgrading the first thing to do is read up on the changes between your versions and make sure that any deprecated features you now rely on aren't disappearing from the version you are moving to. They'll know of any caveats or things to watch out for.
The Data Migration Assistant will help identify issues for you.
If you're hosting applications and data from other vendors give them a call and make sure the version you are running is supported on the version of SQL you are moving too. You may need to plan some 3rd party application updates before you can upgrade or you may not be able to upgrade to the latest SQL if not supported yet by the vendor.
I've used in place upgrades when the business were too worried that migrating every database, user, login and replication configs from a fairly old system with little documentation, without losing data or extending downtime, was too risky. An in place upgrade allowed us to keep these things exactly as they were originally with minimal effort. Over time we were able to move away from the old legacy databases and systems so future upgrades can be done via migration instead. (SQL2008 -> SQL2012)