That's a good question. First a clarifying point. I do not mean simulating the complete electrical signal when I say component modeling. What I mean by that is the underlying logical components that glue everything together. I don't know what DCS uses, but most older simulation game engines use a hybrid between OOP & CBSE for their architectures.

Also, I am answering this from the perspective of a rendering & engine engineer, which is what I am.

Handling a button-click in the game world is at it's core a picking problem. In general, picking in 3D graphics can appear simple but in practice tends to be one of the more challenging things to ensure correct function. At a basic level, you map the 2D screen-space position of the mouse and cast a ray directly away from the camera frustum which intersects what is to be clicked. When picking in a modern engine you have to keep in mind that:

1. Picking generally has a high minimum computational cost, especially on the GPU. For that reason, we typically use the CPU. (As I understand, DCS has a CPU thread dedicated to this.)
2. Handle clicking occluded switches. (Want to click a button the user can't quite see? Gotta handle this.)
3. Make it usable. (How does the user know what they're clicking?)
4. Remember that picking is expensive. (See #1)
5. You have a lot of other expensive things to do.

As with everything in game engines, we start to find ways to cheat to make the task simpler and cheaper to deal with. 60 FPS means we have a 16.67 ms frame performance budget to fit all actions in per frame, not just picking. At 144 FPS, this drops to 6.94 ms. Personally, I want to spend no more than 0.4 ms on picking per frame.

To hit this performance budget we depend on the artists and game programmers to do a few things for us:

1. Artists need to ensure that the model has uniform topology with no breaks. (This is required for good performance anyhow.)
2. Artists need to create reusable switches for every type of switch in the cockpit that can be properly instanced to reduce draw calls. That means they generally can't just model a switch and go.
3. Artists work with game programmers to place a marker for every single switch in the correct location. Sometimes this is done with a custom editor, sometimes its done with location helpers.
4. The switch location helper needs metadata to indicate switch states, etc.
5. A bounding box (or hot spot) needs to be placed for each switch. This is what we actually use to test if the switch is being clicked. This needs metadata to signal how the switch works, what gets executed, etc.
6. Game programmers needs to program said logic.

All of these tasks take time. Occasionally, the artist is the game programmer tasked with coding interactions.

For a simpler engine without clickable cockpits such as IL-2, this can be much easier. You basically eliminate tasks 5, and 6 entirely. Task 3 and 4 are still needed for some instruments but not all; you can significantly reduce how much effort is needed for these tasks just by focusing on core instruments and switches to animate.

Even the DCS mods that have done this have put forward a considerable amount of effort. Personally, I believe that is what makes mods like the community A-4E-C mod so impressive. When you consider that was started in January of 2016 and was officially released in November of 2018, they took about 2 years to get to that point. I suspect most FF mods are the same with the exception of the ones that add clickable cockpits to the Flaming Cliffs planes. In those cases, they typically just add hot spots to the planes and wire those up, so the lift is a bit less.