Once you fail over to the higher version, you cannot go back down.
Using Distributed AGs for a mixed version topology only works when the writable main AG (specifically individual the read/write replica) is on the lower version. From the docs (bolding mine):
Distributed availability groups in SQL Server 2017 or later can mix major versions of SQL Server in the same distributed availability group. The AG containing read/write primary can be the same version or lower than the other AGs participating in the distributed AG. The other AGs can be the same version or higher. This scenario is targeted to upgrade and migration scenarios.
This is essentially the exact same restriction that is in place with using log shipping, mirroring, etc to do upgrades & migrations to new versions. The higher version knows how to read in data from the older version, but the older version may not be able to accept changes from the newer version (new features, etc).
Why do they do that?
When software engineers were building SQL Server 2016, they had no idea what changes might happen in 2017. Since they do not have a time machine to properly handle future changes & features, the older version must refuse those changes.
Additionally, 2016 can't just accept 2017 data until it hits something it doesn't recognize. The 2017 data stream is essentially an unknown data format. Since the older version may not be able to accept some data correctly, it must refuse all data. Accepting an unknown data format & attempting some sort of "best effort" would risk data corruption on the lower version, and raise a large number of scenarios that would have to be anticipated & supported by SQL Server. Protecting data integrity is a primary goal for any DBMS, so sending data to an older version is considered an unacceptable risk from that regard.