[Gary Huff] "Actually, the MJPEG codec is quite efficient as far as CPU decoding power. "
By "inefficient" I meant the normal use of the term in codec technology. E.g, the "HE" in HEVC means "High Efficiency". This means coding efficiency, not computational complexity. MJPEG is invariably described in the industry as "inefficient".
However the term as I used it could be misleading. The difficulty the OP stated was more likely due to an I/O limitation than a CPU limitation. The low coding efficiency may have increased the I/O rate such that performance lagged.
In my tests of 500 megabit/sec 4k MJPEG material from a Canon 5D4, the playback CPU levels are lower than 300 megabit/sec 4k H264 intra material from a Canon XC15. However the 5D4 MJPEG content required an average of about 60 megabytes/sec just to play at 1x, whereas the 4k H264 intra content only required about 40 megabytes/sec.
Both of those 4k codecs can be smoothly edited in FCPX on a 2015 iMac 27 without using proxy -- given a good disk subsystem. They are vastly smoother than typical 4k H264 long GOP interframe material.
So if he cannot smoothly edit the 5D4 500 megabit/sec MJPEG material, he either needs to upgrade his computer, his hard drive, or transcode to proxy.
Even though the 5D4 has been slammed for using the MJPEG codec, it is actually roughly equivalent in coding efficiency and quality at a given bit rate vs H264 intra, and even better in some cases. I think what people really wanted was an interframe option which would lower the bit rate yet preserve a lot of the image quality for many scene types. But in the OP's case that would likely have not changed his situation, as it would have then lagged from inadequate CPU instead of inadequate I/O. In either case he'd probably have to transcode to proxy.
See below paper "Performance evaluation of Motion-JPEG2000 in comparison with H.264/AVC operated in pure intra coding mode" (Marpe, et al, 2004):
https://pdfs.semanticscholar.org/c536/1ffbae7992e26a934682ca4892d066005cc2.... 
