Some perspective about game software development...

I work in the game industry, and what takes so long is implementation -> QA -> iteration -> start over. You don't just sit down with a design document as the project begins and plan out every feature and keep that feature list locked for the entire project.

Sometimes, even post release, a planned feature gets scrapped because it turned out to not work as the designers intended. A good pinball example would probably be "The Captain's Chair" as printed on the playfield of ST. It could be that missions used to be very difficult to complete and didn't have 3 levels each, and so completing 3 in a row was a big deal. Gameplay iteration could've taken them down a different path that was more (for lack of a better word) fun. Now missions are easier to complete, and so lighting 3 can't give the printed award without negatively impacting gameplay. So the newer version may be misleading, but it's better to mislead than to continue down a design path that doesn't work. I have no evidence that this is what happened... it's just a theoretical example based on my experience.

Also, if Stern operates like a modern game company, there is a great benefit to releasing lighter software into the wild with the intent to improve it. You have some machines in the public and periodically collect analytic data, and that data will inform the post-release development process. No amount of in-house testing can possibly compete with that.