An interesting outgrowth of NIH, including and especially places where the choice is defensible (as in the article), is that quite often the external dependency universe evolves or changes sufficiently to put you at a material disadvantage for not participating.

I worked somewhere in the 90s that had built its own database infrastructure to meet business requirements that existed in the early/mid 80s. If you set out to build the same system in 1995 that they'd built before, you absolutely would NOT use the same approach, but they plodded along with a mishmash of internally developed tech for a long, long time -- long enough that it really hurt them. And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases.

It got hard to hire anybody but fresh kids, most of whom would split after 12-24 months.

So even if you do build your own C compiler or whatever, you have to keep an eye out for offramps to that internal dependency if the realities around your product or project change. In this sense, your internal dependency is no different than an external one -- you've always got to be looking for an alternative even if you're perfectly happy with the current path, because the current path might stop being viable.