Obviously, all analogies break down eventually, but I would say something similar to the article: if you anticipate needing to swap some component out, or you are concerned that some activity contains substantial project risk (in the analogy, this is chopping peppers while onions are frying and hoping that no one orders another dish) will be needed during a period of high pressure (lead up to a release, say), try to front-load that effort into a more forgiving timeframe (i.e. chopping peppers before the restaurant starts to take orders). Do the experiments, write the documentation, make sure everyone knows what's going on, then, hopefully, it's less project risk at a time when you can't afford it. You're saving risk, not necessarily time. And you can't eliminate all the risk.
If that's just not possible because you're too busy 100% of the time, you're probably on a death march and it's already too late: once the orders are coming in, if you haven't prepped the peppers, you just have to deal with it, and if that makes any dishes late and customers angry, tough.
I think another important difference is that software is much less predictable. Thanks to low/zero-cost replication, we spend much more time doing something novel than a commercial chef does. If a developer is doing the same thing over and over, that's a an opportunity to extract a service or a framework or a library. Whereas restaurants have much more predictable workloads, making it much safer to, say, chop 100 carrots than to write 100 classes in advance of need.
In a commercial kitchen, you'd better have the peppers (say) chopped and ready so you can use them. Not only for a single serving of one dish, but for all plates you expect to make of any dish with chopped pepper in it.
You cannot pipeline chopping the peppers with frying the onions when you are preparing several dishes at once like you can at home. At home, you have maybe a dish or two, and you know you have time while the onions are frying. You also know that these are the only dishes to be cooked and no one is going to order something else while your onions are frying.
It also applies to software. If you're in a calm, steady development flow, you can pipeline tasks as you need. You can work on the docs while blocking work on the library, it doesn't matter. However, when you'be got periods of high-speed, fast-paced environment with deliverables required right now and bugs flying at you, finding a way to move groundwork out of the stressful time is a good idea.