I think it is worth trying to relate it to lived experience and ask "is this actually a problem or are we imagining problems that are unlikely to manifest?". I

I think it is worth trying to relate it to lived experience and ask "is this actually a problem or are we imagining problems that are unlikely to manifest?". I used to develop in Java in large organizations for many years and be responsible for deciding how we use the language, what libraries we use etc. I used to be pretty hard on developers who would choose third party libraries for anything the standard library already delivered. Even in cases where third party libraries were perhaps a bit better than the standard library. They'd have to offer a clear and significant advantage over the standard library over time to warrant consideration. Especially if we're talking about core functionality or something that would be expensive to replace later. Every third party dependency you introduce is a potential problem because you have to track them. You have to care about their development and release practices, you have to track their license (which may change), the health of the project, you have to know how they respond to defects being discovered etc. You have to do this for every single piece of third party code if the code you work on is critical to your business. My real-world experience is that third party code carries a much higher risk than whatever you depend on from a standard library and you can make mistakes that end up being extremely costly.