Interesting question. As you mention, there seem to be a spectrum of potentially valid answers, depending on which individual, team, or even platform you ask / talk about.
Personally, I try to make an informed gut-feel decision about the short term and long term benefits of pulling in a library for anything. The main inputs to the decision are how difficult rolling my own would be, whether there are any complex risks (such as security implications I'm not well versed to handle, or other such topics), and how much use / mileage we will get out of the dependency. Very often this comes down to whether you've done something similar before, and are confident that you can handle it well enough. I think I tend to lean towards rolling my own, or "NIH syndrome" a bit more than the average developer, but this is for a few reasons. Take this with a pinch of salt, and for context, I would of course agree with not rolling your own crypto, etc - I'm mainly referring to the gray area in the middle.
1) It's usually quite difficult to find a library that nails the level of complexity vs pay-off that I want in a solution. Most of the time, libraries that I find are a complete overkill for my usage, or have large surface areas that I don't need / want. If I can roll a custom implementation in under 50 lines of code, I will generally do so.
2) While you often get immediate payoff for pulling in a dependency, that payoff very often turns around and becomes a net loss of time the moment you run into a complex problem. Pad-left is a silly example, but I think we've all encountered situations where we pulled in some library only to run into a strange edge case. Having wasted a day, you're then thinking "I honestly could have done this better, given a few hours".
3) This point tends to depend a lot on the exact environment you're working with, but managing dependencies can be pretty painful. As a simple example, I've had a number of Angular and Ionic projects with a large number of dependencies become extremely non-trivial to upgrade. If you're talking about a small number of such projects which are frequently worked on (say, flagship apps of a startup), I suspect this is not much of an issue. When you're dealing with dozens of apps for a large corporate, some of which may only get attention in a year or so, this can be a painful burden. A hilarious parody of pad-left is "is-thirteen" [1], which drives the point home for me.
4) Rolling your own also tends to architecturally firewall your implementation (if you've done it right). I.e. it is easier to take your custom implementation and just point it at a 3rd party library, than it is to migrate from library A to library B, if you haven't firewalled them nicely.
The number of times I've regretted rolling my own has been far outweighed by the number of times I've pulled in the wrong dependency.
In summary or as examples, I would never willingly pull in "pad-left", would always stick with a well known UI framework rather than roll my own (primarily for various security reasons), but have written simple templating engines, markdown parsers, etc, without regret. On the other end, I would never roll own crypto, and would be highly hesitant to even come up with my own crypto schemes involving well-implemented crypto, as those can be just as weak.
[1] https://github.com/jezen/is-thirteen#is-thirteen