The "good" example for LP2 says span<string> when it means span<char>.
LP3's example is not very good, because surely real code (even if not latency-sensitive) would just document this precondition, maybe even use C++2a contracts to document it, but never even check it, let alone throw if the check fails. (And if we do bother to check and the check fails, we'd probably just abort(), in the absence of any motivation to do otherwise.)
LP4 is slightly misleading when it equates TriviallyCopyable with StorableInRegisters. Trivial copyability is currently necessary, but not sufficient, for getting passed and returned in registers. For example, std::array<int, 1000> is trivially copyable on every implementation I'm aware of, but it will not be passed or returned in registers on any ABI I'm aware of. I would prefer to see the pro-TriviallyCopyable position motivated by something other than ABI concerns, and then a separate guideline that gives motivation and strategies for reducing the overall size of your data types.
I wish the examples for LP4 didn't use `rand()`. How about using something like complex<int>::operator+ as a motivating example?
LP5 looks incomplete, and/or maybe the final page wasn't meant to be blank?
HTH,
Arthur