FLAC was constructed for ultra-light decoding. Look here: https://hydrogenaud.io/index.php/topic,82125.0.html for numbers on Rockbox devices, which would - to save battery - clock down and not go faster than necessary. FLAC is so "simple" at decoding that you can decode some samples by hand with pen and paper, and indeed if you look at the IETF draft, the appendix carries out decoding of minimal .flac files in detail. Latest at https://github.com/ietf-wg-cellar/flac-specification/releases/tag/draft-ietf-cellar-flac-14
A bit of history with all reservations for accuracy; bear in mind that WavPack the algorithm is older than both FLAC and Monkey's. (Indeed it inspired the creation of the latter.)
Monkey's and TTA are "symmetric", and so was WavPack (I think?) and OptimFROG in old days: you would decode using the encoding algorithm in reverse, taking the same time. Heavier compression? You had to fire more effort at it, in both directions.
I guess we were many who had the gut feeling that if hard drive space was the limiting factor, then you would need that. So Monkey's users could save $$s on hard drives and that codec had a heyday some twenty years ago. But when Monkey's introduced the "Insane" level, there were portable players that could play in principle play it, but not in real time. Meanwhile, FLAC would play at longer battery life than MP3.
Then came TAK. Asymmetric, somewhat heavier on CPU than FLAC, but compressed like Monkey's High (nearly by the tests performed then). TAK changed our perception of what was possible with an asymmetric codec.
Josh Coalson, the creator of FLAC, had a comparison of the codecs available then. This is the oldest web.archive.org version that has decoding times - when FROG had just become OptimFROG: http://web.archive.org/web/20021017022735/http://flac.sourceforge.net:80/comparison.html
It should be noted that WavPack's fast mode was faster at version 3.97, both in encoding and decoding, than early FLAC. You can see that -5 didn't encode particularly fast at the time, but FLAC was to improve. Note, FLAC and Shorten (and in part some RKAU mode) did exhibit this big asymmetry between encoding time and decoding time.
Fast forward to 2007: http://web.archive.org/web/20070823070902/http://flac.sourceforge.net/comparison.html
Now, what has happened since 2002? Except a few new ones?
* FLAC has become more efficient. Most recently also in the fastest encodings. But FLAC works as follows: try many possibilities and pick the best. None of them are heavy at decoding. And by trial and error one has found ways where FLAC can try fewer without having to do so much brute-forcing. You can put the reference encoder at work trying out > 1000 different parameter combinations (per frame) if you seriously want to see how low bang for the buck you can get.
* Among the "symmetric" codecs, both WavPack (the -x) and OptimFROG has gotten "extra encoding processing" which does some of the same: spend more effort on encoding without hurting decoding. But Monkey's has frozen its bitstream: given the signal and the mode (say "high"), the encoded bitstream is determined. Encode a CD with the newest Monkey's - it will be bit-identical to a 3.99 encode. TTA also has a bitstream determined uniquely by the audio - the only thing that could improve would be code optimization.
* We know more about compilers; build matters! https://hydrogenaud.io/index.php/topic,123025.msg1029768.html#msg1029768 .
* And CPU matters. When ktf recently switched his comparison studies from AMD to Intel, WavPack performance numbers suffered compared to FLAC. But meanwhile there was a test on Celeron, where all for sudden the fastest TAK mode would decode faster than FLAC.
* High resolution audio has started messing up what we "knew" from typical CD audio. Especially since a lot of "high resolution" has very little content in the top octaves or the lowest bits.