My only objection to you proposing this is that it's clear to me from some of your early statements in this message that you actually intend to use the MAC address from the relay agent option as an identifier in place of DUID, and not as a hint for your back office system to use in connecting DUID-based identifiers to MAC-based identifiers. This is unnecessary--what you're proposing completely solves your problems without requiring any change to RFC3315 or RFC4361.So these are the motivations behind our desire at least to provide the chaddr in the DHCP packet as a way to identify and classify clients. As I said in my other email, we have a working prototype that does exactly this for ISC dhcrelay.
So if you were to propose a protocol extension that included the MAC address in the relay agent options, and you were to describe how it could be used as a hint to relate DUID-based identifiers to MAC-based identifiers, I would be in favor of that. But to the extent that your proposal essentially substitutes this relay-provided identifier for DUID-LLT, this would eliminate an identifier that is the same across all interfaces for the same device, and I would not support that.
One bellwether of this would be whether or not you expected a PXE boot loader that sends a different identifier than the OS client to get the same IP address that the OS client gets, because the relay-supplied MAC address is the same. If you expect this, your spec breaks interoperability.