Whenever I want a build without vboot I get really annoyed about this hardcoded dependency, even when vboot is disabled in Kconfig.
Would a patch to make the dependency conditional on Kconfig get accepted?
I should hope so, though I recommend starting a new thread to see if experts on vboot can chime in and explain why this is or isn't a good idea.
vboot is used for more than just boot verification these days, we use it as a sort of generic crypto toolbox for all of coreboot's crypto needs (because it wouldn't make sense to implement, say, SHA-256 algorithms twice). For host utilities in particular, some of these are needed in cbfstool (e.g. for the --hash-algorithm parameter to add a hash attribute to a file), and there is no Kconfig cbfstool so you can't just configure it out if you don't need it.
I don't think it's fair to single in on vboot as the big problem here. We vboot developers are definitely not trying to make this hard or obnoxious for anyone, and while it is hosted in a separate upstream everyone is welcome to submit patches to that just like you can do to coreboot (e.g. Idwer submitted some stuff to fix compilation under FreeBSD recently) and I'll do what I can to help get them landed. But none of these problems are really vboot-specific -- the situation is just that there is no official toolchain for coreboot host utilities, and the only testing we have is for exactly what Jenkins uses (which I believe is the same thing used for crossgcc? +Patrick to keep me honest). Anyone can land a patch that uses a GCC 8+-only feature in cbfstool just as well as in vboot and it will cause exactly the same problem.
So I think the "official" rule is basically that the minimum requirement for host utilities is the same compiler and version that crossgcc uses, which I think makes some amount of sense (otherwise we'll just have to keep tracking and deploying two separate versions). If you guys want to change that we can have that discussion, but whatever we decide it's probably not going to be a very effective decision unless someone puts in the work to really make Jenkins test that continuously. And either way, I don't think any of this is vboot's fault in particular (vboot uprevs are tested by Jenkins just as much as any other patch and have to pass any compatibility tests enforced there).