As I understood it, those were not the two options discussed in the article.

Instead it was: use the color values specified in the code, ignoring that screens have changed and that they won't look the same at all, or account for that and make it look right.

The goal is really emulation, making it look like the original. Making games look better than the original is a harder job, that's more remastering the game to take advantage of newer hardware, like what is done on rereleases for new systems.

There are two kinds of emulation, though. There's emulation of experience, and then there's what an AV engineer would call a "monitor": a reproduction that shows you the data the system puts out, as-is, without any "client-side" transforms, even if most end-user equipment does them. Flat response curves and all that. In emulation, monitor-type emulators are often associated with debuggers, or a component of them.

Monitor-type emulators are more helpful in a platform SDK, as you can view the output of them through different end-user equipment to determine how you want to "master" your game's assets. Given that byuu's emulators aim to be cycle-accurate and bug-for-bug compatible with their consoles, they're pretty great for developing homebrew against, so I'd expect at least the option to have a "monitor" mode for video (and audio!) output.

Kind of curious what you'd use the monitor-type for in this case. For example, the gameboy one, you'd want to be able to see the jank oversaturated colors that are only there to make the actual screen display slightly better? Or maybe that one is just a bad example?

No, that's a perfect example. You'd want to be able to see those colors, to be sure that those are the colors your program is actually attempting to render. When you see the "right" jank, that means you've mastered everything correctly and it'll look right when you write it to a cart and test in on real hardware. It's a way to eyeball the intermediate layer, to know when things are going wrong at the intermediate layer, without having to interpret the problem "through" the filters that apply after it.

Interesting, thanks for explaining that.