Update stats w/full scan on SQL Server 2014 uses 100% cpu, on 2008 R2, 15%
Statistics updates can go parallel based on a lot of different options in SQL Server:


Cost Threshold for Parallelism - a query must be this high to ride the parallelism train. Your two servers could have different CTFP settings that cause the 2008R2 update to go single-threaded, whereas the 2014 one can go multi-threaded.
Max Degree of Parallelism - dictates how many cores a query can use, at most, if SQL Server decides to parallelize it that far. The 2008R2 box might have MAXDOP set to 1, whereas the 2014 box might have it set to the default of 0 (unlimited.)
Resource Governor - this Enterprise Edition feature lets you throttle different groups of users or applications to different MAXDOPs.


In later versions of SQL Server (2016 &amp; newer), this gets even more complicated:


Database-level scoped options - you can right-click on a database, go into properties, and set the MAXDOP level for that database.
Statistics parallelism hints - starting in 2016 SP2, the statistics creation &amp; update statements accept MAXDOP hints


As you noted, your 2008R2 one is going single-threaded, whereas the 2014 one is going multi-threaded (thus finishing faster, but maxing out CPU while it runs.)

To find the right balance for your stats jobs, think about:


What other workloads are happening in the database at the same time? Can you afford to dominate the box during brief periods? For example, in data warehouses that sit idle during most weekend hours, I've seen folks crunch hard on stats updates with fullscans when they know nobody's using the server anyway. In heavy-duty transactional environments, you have to start using less impact for maintenance tasks if users complain even during midnight periods.
Is fullscan really necessary? Are you seeing queries that only get good plans when you use the fullscan option, or are you merely doing it as a best-practices thing? As your database grows, if your hardware investments don't keep pace, you may have to start making tradeoffs in stats sampling rather than doing fullscans.
Can you update stats less often? For example, update 1/4 of your stats each weekend, and then every month, everything will get stats updates?
Can you update less objects? Often I see folks updating stats even on huge audit or archive tables simply because a few dozen new inserts were done, but those inserts don't really affect the stats on the table (and nobody's querying it anyway.)