Well it matters when you roll it out at scale. I suppose client side you don't have to worry too much. I think it's still a bit lazy but it doesn't have too much of an impact on small projects. But, as an example, the last company I worked at we made a neural network engine from scratch because we were just not happy about the available frameworks, their heavy dependency usage, and their very specific requirements of os and language versions. In our tests while I was there, we were able to get 3 times the speed up against the fastest framework of the ones we tested, which was Tensorflow. A lot of the speed up came from just taking good programming practices into account and knowing the system in and out and potential weak points. That's how much the dependencies were killing the speed. Since I've left, that's one of their main things now, just making high quality machine learning modules that get the best bang for their buck.

So yeah, I'd say the dependencies are pretty bad. It's a process outside of your control and you kind of just have to deal with whatever is under the hood. More importantly though, what's under the hood was likely meant to be general purpose and there is more than likely a better way to do it for your particular situation. And as she mentions a lot of the bugs are indefinitely there so you just have to have permanent workarounds, which is never good.