So I am a software engineer, but I have no knowledge of Stern's actual development process. But if I am guessing:

While the SPIKE core system stays the same, each game has a new set of mechs and configuration of hardware (lights, switches, etc) I'd imagine that each feature and toy is what they end up coding before the release, individually. Then they run that software plus the mechs in that test room for hours and iterate over the mechs. Then you gotta put all those individual items together in a game and get the rules and lights working minimally to ship. At any time if the mechs are delayed you are holding up the rest of the dev on that game, and you have to know ASAP whether the mech is a go or no go, or requires key mechanical or software redesign. Because if the original concept for toy A needs a major rework then the art team needs redesign, and the licensors might need new approval, and playfields can't be cut until all that shit is figured out.

The light shows and rules and music cues and all that are what we see and think are important but it's the LAST thing that needs to be done because it doesn't hold anyone else at the factory up. And it can be iterated over without hours of mechanical testing. Basically if they are working on this stuff 3 months before shipping something is wrong. It sucks but I think what is happening is they have just enough bandwidth workwise to get the games 1.0 working out the door and have to crunch to make those dates, so they don't have any time left over for rules or maintenance. It's tough but I also understand sterns position. Software engineers are probably the most expensive salary at Stern. And I bet these guys could skip town and make more money working for some lame startup. So they can't really hire their way out of it.

Not to mention on a team of six at least one or two devs are working on R&D like next gen board systems, new display techs, experimental toy designs for a game designer, etc.

Anyways my .02c . I love pinball but even if embedded systems was my thing I doubt I'd work for Stern because I could make more money with less crunch time working for a web or app startup.

No. Every mech and coil has different pulse times and use cases. And they all work together. the engineer has to write a test harness for the basic performance of the mech, including mech code to actuate the mech and switch code to read inputs. And display code to read data back so the Mechanical engineer can monitor. Then he has to write use cases and work flows for actual game performance. Software engineer has to build a state tree so that the game never gets confused about the mechs state or game state. And then the software engineer has to, based on test data, program features so the game behaves ok with a switch out or other flaw.