I don't think "critical" is the right word. Every single software layer you build on top of is "critical" (down to the OS doing malloc and threads correctly, etc). If something is both critical and already pretty bulletproof, it does not make a lot of sense to go there.
I don't have any generalization to offer, I personally make the reuse-or-build decision on a case by case basis.
There are a lot of factors (assuming it's something that is really a fit or near-fit in the first place):
- the scope of the library in question (feature set can be both too small or big, it depends on the situation if either of these things is a problem)
- the maturity (age, testing in place, testability)
- the subjective reputation/community factors can play a role
- the amount of time you have vs. the costs of implementing (duh)
- usually the licenses present a problem
- the depth of understanding I want/need to obtain (an important point that the article is touching on)
"Critical," to me, means "what your clients/customers are paying for," or perhaps "what you're competing on with those in your product space."
Facebook's critical features are the friend network, the information page, and the wall. Facebook would be stupid to write their own HTML rendering library. They would be stupid not to make sure they have the optimum data structures and indexes underlying their relationship graph, and therefore probably wouldn't use an off-the-shelf FOAF library.
The best way to have a really good product is to write all the critical stuff from scratch.
The point of wisdom is to be able to determine what is actually critical and what isn't.