To be fair to people using 'a/'b-type variables:

1) They are used pervasively in the standard library and its documentation.

2) Due to lifetime subtyping and implicit bounds, descriptive names may be inaccurate. For example, if I have an Ast that contains slices with a lifetime of the source code, I might decide to write Ast<'source>. However, what do I do if I then have a reference to such a thing? Do I add another lifetime parameter, e.g. &'ref Ast<'source>? If I am not going to be returning any of the 'source-lifetime slices, this additional parameter may be redundant. In such a case, do I write &'source Ast<'source> or &'ref Ast<'ref>? Both of those names are incorrect. Do I keep around an extra lifetime parameter to get the correct names (and be more future-proof), or do I just suck it up and use 'a?

This is a non-problem, or at least a non-unique problem. It is the exact same thing as using variables as function parameters. Sometimes what the variable means in one place is different from another place, so... you use different names. This surprises no one except maybe first-time programmers. Sometimes a variable means nothing and we can give it a single-character name, but then we shouldn't have a bunch of them to get confused by.

Nearly every Rust tutorial/blog/reference I have come across uses single letter names.

It's a "problem" in the sense that it's additional syntax with critically important meaning to the understanding of the code. The descriptiveness of the labels may help, but it won't eliminate the additional cognitive overhead required to mentally parse and reason about the code.

Lifetime variance often makes it so that more descriptive names are misleading.