I don't disagree, probably. I keep finding myself working on internal projects that are driven by a UI and have little business logic but lots of I/O to other

I don't disagree, probably. I keep finding myself working on internal projects that are driven by a UI and have little business logic but lots of I/O to other systems. With no hard requirements, no guarantee of shipping and no direct access to end users. Which I find less suited to unit tests than (automated) integration testing. As soon as you put unit testing in all anyone can ask is what your test coverage percentage is and why it's some value less than 100. Unit testing is a dev tool, if a dev sees value in writing and maintaining a given test, great, otherwise it could just be that it's not a panacea. Let them strike a balance but ensure the team ask the question of any production issues - could a unit test have prevented this?