That would be because the
[...] matches on a character.
sed would try and match characters against the range specified in
[...]. In UTF-8 locales, you can only encounter
\x8f as part of a multi-byte character. You'll notice that
. doesn't match on it either (and that's a POSIX requirement).
would not make sense.
é is a character (encoded as
0xc3 0xa9), 0xa9 is not a character but as a byte, can be found inside a character (like
e is a character (encoded as 0x65). You can't expect
sed to somehow be able to match 0xa9 both inside a character and as a byte.
To match arbitrary byte data with a text utility like
sed, you'll want to use a locale where characters are bytes, that's a typical case for
LC_ALL=C sed 's/12[\x8f\x9f]//g'
LC_ALL=C sed "$(printf 's/12[\217\237]//g')"
Note that you can't expect to process data containing NUL characters (or that don't end in a newline character or where newline characters are more than a few kilobytes appart) portably with
perl -p/-n instead in that case.