I haven't seen Vladimir's work, but based on your description, I don't think we disagree at all. What you/he label "volatile" dependencies sound like Service implementation dependencies ("Service" in the DDD sense) as opposed to Values (again in the DDD sense). In essence, I freely put interfaces (and therefore test doubles) in front of Services and rarely in front of Values. We might differ in intent or framing, but otherwise it sounds pretty similar.
You might be referring to "Beyond Mock Objects" where I show the refactoring from a function that talks to a supplier of a value to a function that simply accepts the value as a parameter, which eliminates a stub (by eliminating a possibly unnecessary level of indirection). I tend not to think of test doubles as a sign of a design risk--it depends more on the presence of irrelevant details in a test, and needing to stub or mock something can be irrelevant just as the implementation details of a collaborator can be irrelevant.