Actually directly switching on vendor seems fairly bad. However, to the extent that downstream changes can be encapsulated into options/deltas that someone might want, I think it may often be reasonable to carry the delta in Debian.
So imagine that Ubuntu and several other downstreams care more about security and hardening than they do about backward compatibility and they choose to change a number of gcc and other tool defaults in support of that. I realize my example is not entirely hypothetical, but I want to emphasize I have not researched to get all the details right, because it doesn't matter. Especially if multiple downstreams or individual users who build from source might want the change, I think carrying the delta in the Debian source package can be valuable. It needs to be balanced against a lot of other concerns. However, I do tend to agree with Ian that actually turning on that delta in a specific vendor environment may be best carrief as a vendor-specific source package. That said, even there there are tradeoffs. As an example, Ubuntu tries to use unmodified Debian source packages where possible. In some cases I think that the maintenance advantages of doing this and the slight but real political pressure it creates to push changes upstream to Debian may justify switching on dpkg-vendor. I think my point here is that there's a lot of complexity, and I'm not even convinced it would be desirable to recommend against using mechanisms like dpkg-vendor. I think what we can hopefully all agree on is that the dpkg vendor patch series as bad. Perhaps before we go and recommend something specific we can actually write up some of these tradeoffs and give people the information they need to make informed decisions. And yes, in many cases dgit is the answer. That said, if I were maintaining the same package both for Debian and for the downstream I work on, I might well value having a single source tree enough to use dpkg-vendor or lsb-release or something to switch.
