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.
But note that 'bool' in Python is not subclassable.
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."
Then again, someone who tries to understand your version beyond "fuzzy matching of words while ignoring stuff they don't comprehend" (that's a real thing and we all do it all the time :-) might be confused by the conundrum posed by a parameterized boolean.
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.
So maybe you should just stick to "bool". TypeGuard is really only useful for people who care about what type checkers do (a surprisingly large contingent, actually, but I would not recommend it for the education department).
And I'm sure that when five years from now you're seeing TypeGuard in the wild, you'll remember this thread and you'll know that it is a boolean. :-)