TL;DR of my TL;DR - Not conveying bool-ness directly in the return annotation is my only complaint. A BoolTypeGuard spelling would alleviate that.
This is exactly my feeling as well. In fact, I do not understand why it cannot simply be a parameterized Bool. That would avoid all confusion. Yes, it's not the technical jargon type system designers use... But the existing proposal moves all the mental effort to non-experts who may never use type checking tools.
I.e. if I read this:
def is_str_list(v: List[Any]) -> Bool[List[str]]:
...
I just think, "OK, it returns a bool, and those mypy people are doing something else funny that I don't need to worry about." If I see TypeGuard[...whatever..] I automatically think "that's a weird thing I don't understand, but it looks like it returns a boolean when I read the body."
FWIW, this hypothetical non-expert is me. I've actually gotten in the habit of using simply type annotations in most of the code I write (a lot of which is for teaching). But I never actually check using type checkers. It's quite likely some of my annotations are not actually sound, but to me they are documentation. I.e. I'll use an annotation of str/list/float, but not precisely parameterized types, union, generics, etc.