basic_format_arg has a constructor that accepts a basic_string_view of an appropriate character type, with any traits type. The constructor is specified in [format.arg] as:

template<class traits>
explicit basic_format_arg(basic_string_view<char_type, traits> s) noexcept;

-9- Effects: Initializes value with s.

Recall that value is a variant<monostate, bool, char_type, int, unsigned int, long long int, unsigned long long int, float, double, long double, const char_type*, basic_string_view<char_type>, const void*, handle> as specified earlier in the subclause. Since basic_string_view<meow, woof> cannot be initialized with an lvalue basic_string_view<meow, quack> — and certainly none of the other alternative types can be initialized by such an lvalue — the effects of this constructor are ill-formed when traits is not std::char_traits<char_type>.

The basic_string constructor deals with this same issue by ignoring the deduced traits type when initializing value's basic_string_view member:

template<class traits, class Allocator>
  explicit basic_format_arg(
    const basic_string<char_type, traits, Allocator>& s) noexcept;

-10- Effects: Initializes value with basic_string_view<char_type>(s.data(), s.size()).

which immediately begs the question of "why doesn't the basic_string_view constructor do the same?"