It really boils down to time and space. Firstly I'm assuming that the server hosting SQL 2012 also supports installing SQL 2014. If that isn't true then the rest of the discussion is mute.
If you do an inplace upgrade then the server will go down while the upgrade is running. You'll likely need to reboot and then you are back up and running. However if anything goes wrong then you'll need to either restore the machine itself or uninstall SQL 2014, reinstall SQL 2012 and restore your DB. An inplace upgrade is designed for cases where you want to replace the existing database server AND you don't want to have to worry about migrating custom settings and whatnot from one instance to another. Of course the instance name is probably not going to change so hopefully you're not using an instance name of
SQL2012 or something.
A side by side upgrade works well if you need to have the DB online while you are doing the upgrade and you have the resources to run both. In this case you would install SQL 2014 (you don't need to uninstall SQL 2012 first), migrate the DB and do your testing. If something goes wrong you still have the current SQL 2012 instance available. But any changes that might have been written to the old DB would be lost after you migrate the DB. Of course you'll need to set up the new instance with all the same configuration your old DB has such as security, and runtime configurations (if any). You could always restore the DB a final time to get any changes made while you were doing your testing. Once you are on the new DB then you can remove the old instance. This might require a reboot however.
All things being equal an inplace upgrade is probably the fastest route. However some old database settings may linger afterwards (such as the accounts being used and configured permissions) so you might run into issues in the future if you upgrade again. A clean install requires more effort but is more likely to be "pure" as it will be using the current SQL settings.