In TS, user defined typeguards are compatible with (...) => bool. However the proposed PEP says: "TypeGuard is a distinct type from bool. It is not a subtype of bool. Therefore, Callable[..., TypeGuard[int]] is not assignable to Callable[..., bool].", this prevents using typeguards as predicates for filtering functions.
This surprises me, actually, as I thought it was intended to be compatible with uses of bool (at least in my mental model). One motivation I would have for making it compatible with bool is that existing functions could be converted to TypeGuard (e.g., inspect.isfunction). Otherwise, existing functions in the wild could not be typed with TypeGuard without forcing odd cases or type ignores... It makes sense why TS is bools; I have seen libs like is-promise get statically typed (even though the underlying code is not TS). It would surprise me to not be able to do the same in Python.
TS does apply narrowing in the negative branch. However, the proposal explicitly mandates not to narrow in such case.
FWIW, we have somewhat regular meetings with the TS folks (pyright's internals are very similar to TS's) and brought TypeGuard up, and I believe it was their impression that their type guards proving the negative in TS was a mistake, and often led to confusion and typings that had to be reverted as they couldn't actually prove the negative. I'm sure Eric knows the exact wording.