Games sure don’t seem to favor fidelity when it comes to the “game” part. :)
So most games tend to go for simple systems presented through enough smoke and mirrors to give the illusion of complexity.
Also keep in mind that games aren't made in isolation, instead they have tropes that players are heavily relying on. A very common example is the "red barrel = explosive barrel" trope. That trope is mostly harmless in that if it doesn't apply (ie. the game has red barrels but they do not explode) then nothing bad happens. But what you are describing with blood trails sounds like the regular cosmetic blood decals almost every action game has that can be easily be missed by players.
But note that i'm talking about the generic action game here, not a game designed explicitly around one of these mechanics - that is another matter since you expect it to be like that. But if these mechanics you mention are used like any other "secondary" mechanic in a game (and especially if it is a game that offers alternative approaches) then it'll fly over most people's heads and be ignored unless the game explicitly mentions it every single time.
And this is normal, there is only so much you can keep in your head while playing (especially if you consider how long some of these kitchensink games are and how little time per day/week some people have).
Hence simple mechanics, smoke and mirrors.
But if you had an in-engine system for doing realistic chemistry (maybe in bulk, on a voxel or particle level, on the GPU) then that’d be less of a gameplay idea, and more a module to drop into a game’s physics, no? Sort of like soft-body dynamics is a module to drop into a physics engine. It’d just be part of the game’s physics that’d constrain the way that a crafting system must be implemented if you’re using it; sort of like how using kinematics engines constrains the way you implement vehicles.
If the entire game is full of tracked atmospheric gases; and the heat of these gasses can convect into nearby solids/liquids; and the gasses can also condense if they get too cold, and things can crash out of liquid solutions if the liquids get colder, etc.; then inherently you’re going to be able to build things like a distillation apparatus under such physics; and inherently you’re probably not going to be able to build a Minecraft-like arbitrary-crafting system without going “out-of-engine” in a difficult way (because now you have to worry about how popping things into existence affects air pressure—you’ll be fighting the “chemistry engine” every step of the way to building it!)
And, also, you’ll get side-considerations, like it being hard not to have a weather system in games using such an engine, because each zone of bounded size inherently becomes a terrarium where the “ceiling” can form condensation. (And there would have to be such a ceiling—in fact, a whole physically-simulated “world box”—otherwise the gas escapes! Unless you want an Earth-sized spinning zone to keep your atmosphere sucked down...) Again, you’d have to fight the engine to use it but not have realistic weather. It’d be a lot easier to “trick” the engine by just putting materials into the game that would have the same real properties that would create an illusion of there being no weather in a real terrarium (i.e. a really big air conditioner, sitting “outside” the terrarium-edge-box, like the ceiling in The Truman Show.)
Or, in the sense of a damage system, I’m not really talking about the gameplay concept of a damage system, but rather choosing to implement player-controllable avatars (and mobs, and everything else “living” in the game) in terms of a scripted or player-controlled “mind” commanding a faithfully biologically-emulated “body” to move (think “body as kinematically-simulated robot, that has a movement AI, and accepts goal-pathing instructions; player control/NPC AI as source of such pathing instructions.”) And, since the body would be physical, entities would only be able to do what their bodies are able to do—such that if an entity’s body gets damage to a crucial muscle or organ, its body is now less able to follow commands to run, however much the control-layer sending those commands wants it to run. Sure, from a top-down sense, that’s a “choice of damage system”; but from a bottom-up sense, that’s a physiology modelling engine that could be put into any game engine and used for any number of things (from a game about trying to stab your opponent in their vital organs, to a game about poisoning, to a Wii Fit-like game that tries to model which of your muscle-groups will tire first, to...)
Consider why we have a “physics engine” in the first place. 2D games back in the 80s and 90s mostly just implemented one-off physics at the application layer; but then, soon after entering 3D, we wanted real physics, and there’s only one “real physics” to model, so we started reusing and generalizing our logic for “real” physics out into physics engines, and started building the “game physics logic” for games that wanted mostly-realistic physics, as just a policy layer on top of such a generic real-physics engine.
That’s what I’m talking about here: there are other such “engines” we could have, which would be scientifically-sound models of reality that players could predict the behaviour of based on their knowledge of the real world, where in-game systems could then be implemented the way most 3D games’ physics systems are: as configurations of, and scripting hooks into, a few polished, flexible, generic models.
https://www.audubon.org/news/birding-its-1899-inside-blockbu...
https://docs.unrealengine.com/en-US/Engine/Chaos/ChaosDestru...
The issue comes with building a system to generate it asynchronously, to load and unload the data in a timely manner, to optimize around common use cases, to plan out memory allocation, and so on. Yes your computer could run it, but game engines are too simple to support the level of complexity to use these kinds of tools dynamically (or even at all sometimes).
Easier to just glom it all into a static world made by artists that are supported by tools like these, and ship it.
To draw an analogy, it's like trying to manage a cluster of a thousand containers across a hundred interrelated applications across a machines with only docker compose when one really needs something like Kubernetes.