It's great to be the sort of developer who reads all their dependencies, what's not nice is forcing maintainers to do that too after you have left - we usually want to expend the minimum effort necessary to keep your application vulnerability-free and still-deployable and do not appreciate "artisanal" takes.
I want to see locked dependency versions and use of company artefact repositories to avoid unexpected changes and avoid availability concerns (e.g. it gets yanked off npm or github etc).
I am not pleased to find vendoring, as I now have to work out what (if any) code has been changed, what version of the upstream it corresponds to, and I now have to potentially merge third party code to do otherwise simple updates. How bad this all is depends on the language and style of vendoring.
The absolute worst case is when someone like the author has vendored everything, deleted half of it, pointlessly eslinted it(!) made a few cosmetic changes here and there, ... "haha good luck merging from upstream now" - it adds no business value but increases maintenance costs.
Depending on tooling, I may now also have to commit to periodic manual review for dep based CVEs instead of just letting the company dep scanner sort those out.
I have no problems with vendoring "for the right reasons" e.g. if you actually needed to change the code to fix a bug or make a change that's fairly specific to your application.