A little bitrate adjusting should get your CPU Usage under control. FFMpeg transcoding is an intensive, yet efficient process, usually able to make due with whatever constraints you give it.
For reference, after my Poweredge 1800 blew out on me (a socket plug on the Mobo literally blew a corner of itself clean off, scorching a few circuits in the process (always check your house's wiring after moving)), I've moved my entire setup to an old Compaq running off of an AMD Sempron LE-1300, Single Core, 2.3ghz, 2GB of RAM. Serving 6 clients, 3 wirelessly through a repeater bridge from my Wireless G 54mbps network to their Wireless N (getting Emby and Windows to allow local network communication across different subnets without name resolution was a learning experience), with a large chunk of my media residing on a failing 500gb drive (my BIOS gives me a not so friendly SMART warning on every boot).
I've now disallowed transcoding to leave CPU available for other backgrounds, but with all these bottlenecks I was able to sustain 2 transcoding streams at a 3mbps limit (never tried higher, only time I bothered with transcoding was when I couldn't get the Android app to direct stream and 3mbps is crystal clear in the palm of your hand) when I did bother with it. With direct play & direct stream properly working for just about all apps (which reminds me, I need to go open a bug report thread), I've moved over to that and can deliver 1080p DDS without a hiccup.
Emby can be a massive resource drain, but a lot of it falls on configuration and library size, other than that it's just a pretty content server at heart and can operate decently in a variety of settings.
Although it can seem CPU intensive, from what I've observed one of the biggest bogs Emby faces is file access and packet delivery, tuning your network for the lowest latency possible, and investing in a small SSD drive for all metadata and transcoding temporary files would speed access and browsing up far more than jumping from a mid/high-end CPU to high/higher-end CPU, (as an alternative to this, I've directed all these functions to a Raid 0 of 2 70GB drives (you can't imagine what kind of issues attempting to read 100s of metadata files from a failing 500gb with the occasional 5s+ response time caused (timeouts, timeouts, more timeouts)).
So if you guys are seeing poor transcoding with quad cores and 16gb+ ram, something I never saw with 4gb and a 3ghz Xeon (a dinosaur in terms of quad core processing technology), I would look first to bitrate settings (full bitrate 1080p transcoding is going to be a task regardless in most conditions) and after that, network conditions causing buffering chokes, and file access (speed of drives, partition health).