I'm confident that you're misinterpreting this statement. It's a functional requirement: the TSF1 must be capable of doing something. Specifically, the TSF must support validating certificates, and it must support a path length of any number up to 3, and possibly more. (There's an implicit assumption that if it's capable of supporting 3, it's also capable of supporting less.)
Semantically, the word “minimum” is about the support, not about the path length. The sentence is badly worded because “minimum” is syntactically attached to the path length instead of the verb.
A better wording would be
RFC 5280 certificate validation and certificate path validation supporting, at a minimum, a path length of three certificates.
A product that only supports shorter path lengths might still be secure, but it wouldn't be considered in scope of that protection profile.
In terms of security architecture, a longer path length has no advantage for the security of the device itself, but it has an advantage for the security of the network as a whole, because it allows delegation and compartmentalization. To take an extreme example, if the device only supported verification against a fixed signature, and not signatures by a certificate authority, then the administrator would have to provision the public key of every entity that the device communicates with, which would be a maintenance nightmare, with a high risk of mistakes and security bugs, and it would make it hard to track credentials and authorizations. Two levels allow for an offline root CA (very well defended but costly to use), an online operational CA (usable but at risk of online attacks) and the end entity. Three levels allow one more level of indirection with an organization-wide CA and a department CA.
1 Translated from commoncriterese: the system whose security is being evaluated.