Yes! Any company that has adopted MyPy or TypeScript often have policies for this. One team I spoke to at Facebook said that any new code should have type annotations. I believe Dropbox had a nice blog post about new code should have type annotations too. It is hard to get these details from companies/teams (and be allowed to talk about it).

That's because (a) these are not historically type-inferred languages–runtime typechecking doesn't count as type inference–and (b) the gradual typechecking approaches like Mypy and TypeScript often have a lot of type inference issues which force people to try to overcome them with manual annotations.

In languages with even reasonably good type inference you'll find that the idiom is not to annotate types at the very least inside function bodies. And in OCaml, which has principality of type inference i.e. the types it infers cannot be overridden and corrected by manual annotation, the idiom is to not annotate implementation files at all.

Do they mandate that only function types (and any ambiguous ones) should be annotated, or that all types (i.e. including those of local variables which mypy can infer) should be? I strongly suspect the former, which implies that they view type annotations more as a necessary evil to allow type checking rather than a benefit in their own right. After all, there was nothing stopping people putting "type annotations" in Python 2.5 code if you wanted, by writing `x = get_thing_count() # int`. But AFAIK no-one did that until annotations could actually be used to check type safety.

Typescript will infer the 'any' type by default in a lot of cases, that's the reason teams will mandate type annotations. It's really just not the same thing. These are bolt on type systems to dynamic languages where if you fail to put a type annotation you're actually losing information. That's not the case in Haskell, type inference causes no loss of precision for types.