The client-id is something that we want to determine top-down.
Meaning, if the user specifies it via ipv4.dhcp-client-id, then it
should be used. If the user leaves it unspecified, we choose a
default stable client-id. For the internal DHCP plugin, this is
a node specific client-id based on

  - the predictable interface name
  - and /etc/machine-id

It's not clear, why we should allow specifying the client-id in
the lease file as a third source of configuration. It really pushes
the configuration first down (when we do DHCP without lease file),
to store an additional bit of configuration for future DHCP attempts.

If the machine-id or the interface-name changes, then so does the
default client-id. In this case, also "ipv4.dhcp-client-id=stable"
changes. It's fair to require that the user keeps the machine-id
stable, if the machine identity doesn't change.

Also, the lease files are stored in /var/lib/NetworkManager, which
is more volatile than /etc/machine-id. So, if we think that machine-id
and interface-name is not stable, why would we assume that we have
a suitable lease file?

Also, if you do:

   nmcli connection add con-name "$PROFILE" ... ipv4.dhcp-client-id ''
   nmcli connection up $PROFILE
   nmcli connection modify "$PROFILE" ipv4.dhcp-client-id mac
   nmcli connection up $PROFILE
   nmcli connection modify "$PROFILE" ipv4.dhcp-client-id ''
   nmcli connection up $PROFILE

wouldn't you expect that the original (default) client-id is used again?

Also, this works badly with global connection defaults in
NetworkManager.conf. If you configure a connection default, previously
already this would always force the client-id and overrule the lease.
That is reasonable, but in which case would you ever want to use
the client-id from the lease?