The only thing I can think of is that you could have

    int mytype;

conflicting with

    typedef struct { ... } mytype;

By putting the "struct" in front you only potentially conflict with other struct definitions.

Is that the thinking or is it something else?

Yes, for pointer types for example type qualifiers (e.g., const or volatile) cannot penetrate typedef of pointer types. So if you use typedef with pointers you are stuck.

It varies a bit by context; Linus's call is likely the right one in the context of the kernel, though to be sure it's not so big a deal that other approaches can't be made to work fine.

You call out one upside - decreased verbosity. The accompanying downside is usually - as in this case, for both structs and pointers - that potentially relevant information is made less visible. Whether it's a good idea depends on how likely that information is to be actually relevant, weighed against the upsides.

Where performance is relevant, you want to be aware of where you're potentially passing large structs around. Putting this info in the type name instead is an option (eg _s), and can reduce verbosity a bit. I don't know of any good reasons to call out structs that are sized like primitives.

The case against hiding pointers is much stronger. Level of indirection can be relevant to performance, and is often relevant to correctness, particularly where mutation is involved. You can put it in the type name, but it's not going to be any less verbose - a star is already one character. I allow a possible exception here for where an opaque type is allocated by a library and passed around as a handle and the client really doesn't need to ever know whether it's a pointer or an int index or what.