Developers assuming that RGB is a triplet of 8-bit numbers and that maths can be naively done to those numbers is one of my favourite examples of the Dunning Kruger effect.[1]
It's such a rarity to see a tool correctly implement color management or linear light for transforms by default that it always jumps out as far out of the norm.
> animated 3D graphics
You'd think so... but no. It's a persistent error in 3D games as well, as well as 3D renderers like Blender.
A common question posted in game-dev forums is "textures look brighter/lighter/faded in game compared to Photoshop". This is because most image editors use the sRGB non-linear gamma, but the game engine uses linear light because it's essentially a physical optics simulator. Beginner game developers load the sRGB 8-bit pixel values and then use them as-is without first undoing the gamma to bring them into the linear light space. This results in over-bright textures. The Quake engine and its derivatives were notorious for this kind of thing, made even worse by OpenGL accelerators like the 3dfs Voodoo card doing more incorrect things on top of that.
Similarly, "Cinematic" mode in Blender should be renamed to "not broken" or simply "correct" color management mode.
[1] I'm guilty of making all of the mistakes I've listed here, in a 3D engine, a ray tracer, and several other graphics utilities. We're all beginners at some point!
[2] The "best" video colorist tool on the planet is not color managed on Windows or Linux. It outputs "whatever" to the screen and ha-ha... good luck. On a HDR screen, with HDR on, if you enable HDR in Resolve you get a washed-out incorrect mess. That just blows my mind.