Isso ocorre porque o [...] corresponde a um caractere. sed tentaria corresponder os caracteres ao intervalo especificado em [...] . Nas localidades UTF-8, você só pode encontrar \x8f como parte de um caractere de múltiplos bytes. Você perceberá que . também não corresponde (e isso é um requisito POSIX).
Por exemplo:
sed 's/[eé\xa9]//'
não faria sentido. é é um caractere (codificado como 0xc3 0xa9 ), 0xa9 não é um caractere, mas como um byte, pode ser encontrado dentro de um caractere (como é ), e é um caractere (codificado como 0x65). Você não pode esperar que sed seja capaz de combinar 0xa9 tanto dentro de um personagem quanto como um byte.
Para corresponder dados de bytes arbitrários com um utilitário texto como sed , você vai querer usar uma localidade onde os caracteres são bytes, o que é um caso típico para LC_ALL=C .
LC_ALL=C sed 's/12[\x8f\x9f]//g'
Ou portably:
LC_ALL=C sed "$(printf 's/12[77]//g')"
Observe que você não pode esperar processar dados que contenham caracteres NUL (ou que não terminem em um caractere de nova linha ou em que caracteres de nova linha sejam mais do que alguns kilobytes abertos) portável com sed . Use perl -p/-n nesse caso.