need for flexibility

In my (limited) experience such a replacement is fairly rare. Normally it is standard procedure to do very careful evaluations and prototyping of third-party components and core components before massive integration into the final engine. Every now and then something will be ripped out and fully replaced, but this is rarely a serious issue; it is also common to build insulation layers between components and the implementation (e.g. a thin wrapper over a netcode library) so that other implementations can be swapped in with relatively small changes. Usually, though, great care is taken to make sure that components are designed/selected appropriately from the beginning.

Maybe we should distinguish two kinds of flexibility:

e.g.
Runtime/devopment flexibility - being able to switch COTS components during development or even runtime. Which may not happen that often.

evolutionary flexibility - switching COTS components during a product's evolution. Evolution has a somewhat different meaning for games; e.g. sequels. If your game is succesful; a sequel is developed. Switching COTS components is more typical, however as most of the game content is different this may not have a big impact on the existing architecture.

From a Cost benefit perspective the need to design a flexible architecture depends on the likelihood of success of your game.

anyone have any ideas on this?

I would posit that any well-factored system will, by nature, exhibit a reasonable degree of evolutionary flexibility. In my mind at least that isn't so much a goal of design per se as a very nice side-effect of a good design.

I agree with that, although one must not overengineer. i.e. a good engineer knows when additional complexity adds value over simplicity in design.