It is fairly common for IT teams to implement features that no one ends up using. Sometimes this happens because the team anticipates a requirement that never actually becomes a requirement. This sort of predictive engineering is wasteful, so there is a popular rule of thumb that warns you against it: YAGNI. Don't implement something unless you know you will need it.
However, when you work on a system over longer periods of time, you will inevitably sart facing choices that either increase or decrease the entire spectrum of options you will have cheaply available to you in the future. The obvious corollary is that chosing unwisely might cost you money in the future. The less obvious corollary is that it might also force you to make other decisions that will futher limit your options down the line. After a few bouts of such decision-making you will be stuck in a legacy system where thre are no good options available at all.
Note that I am not talking about "flexibility" here. Flexibility is usually defined as ability to change behavior of software without modifying it. Avoiding opportunity implosions concerns the ability to change behavior of software by any means.
With all that said, it should be fairly obvious that one of the goals of anyone working on a major piece of software should be maintaining the availability of future opportunities. In practice, it's a concept completely alien to most IT managers and developers.