One problem of having \xHH; mean different things in string liberal and bytevector literal is that when you're editing source and happens to want to change an existing string literal to a bytevector literal, you'd *almost always* be able to do so by just inserting #u8 before it.
I would think it would be easier, not harder. It's true that if you have more than two digits in \x sequences, you'd have to rethink it: what encoding do you want? In some contexts Latin-1 might be as likely as Unicode. But if you had to use \yHH; instead, you'd have to change all of them.
Except for the rare case that string contains \xHH; sequence. You may not always be careful enough (suppose you're editing auto-generated data, for example). It silently changes the content of the literal unintentionally, and may go undetected for a long time.
In SRFI-207 as it stands, such a literal would be a lexical syntax parsing error, and so would probably not in fact go undetected.