/usr is one of the directories we include by default in the list of directories we scan, however by including bin, lib, and others we make sure we don’t miss out on systems that may not have that symlink in place.
The thing about encryption at rest is that the system is often not at rest. The goal here is to detect rootkits that might have replaced system binaries with tampered versions (classic example would be /bin/bash) while the system was running, extending the tamper detection we already perform that would catch rootkits that tamper with the kernel or initrd (or grub config). We would also detect tampering that occurred by an attacker who had access to the system while at rest, who was able to crack the disk passphrase.
PureBoot and Heads needs a scratch space it can read, so it can store the HOTP incrementing counter, so it can parse and display the GRUB boot options, and it also needs to be able to test files in /boot for tampering before executing them. At the moment the simplest approach is to leave /boot unencrypted, relying on the fact that we can detect attempts to tamper with files stored there (and that directory doesn’t contain any secrets).
One downside to encrypting /boot with respect to PureBoot, is that it would require us to prompt the user for a secret before we have authenticated ourselves to the user (specifically to their Librem Key), so we could have access to that HOTP counter. If we could somehow store that counter elsewhere, I suppose it might be OK to prompt them for a secret, once they can trust the PureBoot firmware isn’t tampered with. Unfortunately the TPM only supports a single auto-incrementing counter at a time and that is already being used for the rollback counter in Heads. We do prompt the user for their / LUKS secret to test / for tampering, but only after we have proven the firmware is trustworthy.