Limited compute changes what's actually feasible
A constrained device — a sensor, a small embedded controller, a battery-powered peripheral — often has meaningfully less processing power, memory, and energy budget than a server, which makes cryptographic operations a server performs routinely genuinely expensive, sometimes prohibitively so given the device's power and latency constraints. This forces real design tradeoffs: lighter-weight cryptography, less frequent re-authentication, or delegating heavier verification to a nearby, more capable intermediary rather than the device itself.
Treating a constrained device's authorization exactly like a server's, without accounting for this gap, tends to either overwhelm the device's actual capabilities or quietly get watered down in implementation until it no longer provides the protection it was designed to.
Physical exposure raises the stakes on device identity specifically
A device deployed in the field is typically far more physically accessible to an attacker than a server sitting in a data center — which makes proving the device's actual identity and integrity, not just checking a credential it presents, considerably more important. Device attestation, rooted in key material tied to the specific hardware rather than a secret that could be extracted and copied, addresses exactly this: a cloned or tampered device shouldn't be able to present the same proof a genuine one can.