My response here is mostly that many of the visual choices made in the games I'm criticizing were made completely independently of the game design team. This is far from ideal but it's a consequence of how the production pipeline is set up in these blockbuster titles. I do vehemently disagree that the aesthetic traits I'm looking for are at odds to gameplay and design decisions, though.
I could go on for a while about how Zelda BOTW manages to integrate the design and aesthetic choices, but I'm going to get mugged if I try to use that game as an example again. Maybe I'll use it as part of a different write-up on visual design.
You don't want to encode brightness perceptually until you're showing it to the user. You need a linear space to actually do lighting calculations, which means physical luminance values. Within that space, you can use whatever scale you wish, with consequences to banding and quantization artifacts for decimating the bit depth. Tone mapping includes conversion to a log space via the gamma curve.
I explained it in another comment but basically the "20 bit" value is based on an idealized digital image sensor rather than a game rendering pipeline (which operates in floating point). It has admittedly proven somewhat confusing.
The Switch is perfectly capable of both deferred shading and HDR, which are themselves independent unrelated techniques. You can make an argument about whether or not those are the best implementation trade-offs for that hardware, taking performance and desired visuals into account. But there's nothing inherently preventing you from doing it on the Switch and it's a fairly capable GPU in its own right.
P.S. Unreal Engine reintroduced forward (non-deferred) rendering as an option last year because it's more efficient in VR.
I liked this enough to merit an addition to the write-up. It's not perfect but I'm seeing some great GTA 5 shots that are very nicely balanced overall. Doubly interesting given the substantial age of the game.
This was certainly not meant to be a crucial piece of information, but sure, let's get into it.
Much of the post comes from a general assumption that the goal of computer graphics is primarily to replicate how a camera sees the world around it. Thus I think it's easiest to start from the idea of real world light entering a digital image sensor. Light in this setting is not continuous! Each subpixel in an image sensor acts as a photon counter. One photon hits the sensor, the count ticks up by one. There's no question of being able to perceive the values between 1 and 2 because they don't even exist. Either the sensor counted one photon or two. If you were going to literally create a digital camera that can process the entire world, you need 20 bits to count up to a million photons without losing any along the way. So if you were to build the hypothetical rendering pipeline that works on "real world" data about the scene, that 20 bit value would be the input.
As a practical matter, nearly all modern games store lighting levels internally in floating point, in arbitrary units chosen by the developers. Lighting pipelines are not integer based, but they're linear and not perceptual. The conversion to perceptual 8 bit (gamma curve) happens as part of the tone map stage. Doing things in floating point physical units is a better idea than the photon counter anyway, but the line you're confused about was really written with idealized cameras in mind.
(Technically an image sensor is an analog device and the voltage increases with each photon detection by an increment that is subject to noise of all sorts and pre-amplification before hitting ADC. Don't jump me on the photon counter thing.)
I could go on for a while about how Zelda BOTW manages to integrate the design and aesthetic choices, but I'm going to get mugged if I try to use that game as an example again. Maybe I'll use it as part of a different write-up on visual design.