What a bearer token doesn't cover
Request signing cryptographically signs an entire request — not merely presenting a bearer token as proof of identity, but signing the specific content of this exact request — so a verifier can confirm both who sent it and that nothing about it was altered in transit, independent of whatever transport channel actually carried it. A signed request tampered with along the way fails verification regardless of how it was tampered with, because the signature covers the request's actual content, not just the fact that some credential accompanied it.
A bearer token alone can't make this same guarantee: it proves the presenter holds something valid, but it says nothing about whether the specific request traveling alongside it arrived unaltered. Signing ties the credential's authority directly to the exact content of this one request, closing a gap bearer tokens structurally can't close on their own.
Both sides have to agree on exactly what was signed
This only works if signer and verifier are computing the signature over an identical representation of the request — which is what a canonical request provides: an exact, normalized form, with headers ordered and values encoded a specific way, so two semantically identical requests can't accidentally produce different byte sequences that cause a valid signature to fail verification purely due to formatting rather than any actual tampering.
This is the same underlying discipline canonicalization brings to authorization checks generally, applied specifically to signature verification: just as normalizing an input before a policy check prevents an equivalent-but-differently-encoded request from bypassing it, normalizing a request before signing prevents an equivalent-but-differently-encoded request from failing a signature it should have legitimately passed.