I don't understand what the point of upgrade_effective_block is if you need a quorum of delegates to approve the upgrade. Why not just set upgrade_quorum to something like 81 and then upgrade to the new semantics as soon as (either the very next block or maybe the next round or the next next round to be extra careful) 81 unique active delegates have approved of the upgrade?
To simplify messaging to non-delegates: Tell them something like "The upgrade will go into effect midnight on August 14, you must upgrade your client by then."
Certainty about when and whether the upgrade will occur has more value than having the upgrade occur as soon as it becomes technically possible or leaving the door open to a potential upgrade forever.
Also, I don't get the purpose of the wallet_delegate_propose_upgrade command if the upgrade parameters are already included in the JSON that is hard-coded by the developers in the client.
The hard-coded JSON for a new feature only exists in new clients that support that feature. Old clients won't have the hard-coded JSON, and will need some way to get information about the upgrade. This proposal achieves that by putting information about the upgrade on the blockchain.
And for that manner why would the upgrade proposal expire?
To provide certainty about whether an upgrade will take effect or not, and give market participants time to make arrangements to conduct their business accordingly once they are aware whether the old or new semantics will be in effect going forward.
If it fails to reach a quorum by that expiration, does that mean it becomes impossible to upgrade to that new version? Why? What is the purpose of that?
It won't be impossible to upgrade to the new version; rather it means the semantics changes introduced by the new version will never go into effect. If only 51 delegates have upgraded when the hardfork goes into effect, the chain becomes very fragile. So the solution is to set the quorum much higher than 51 to provide some safety margin.
Again, we say "the upgrade will not go into effect if a quorum hasn't reached consensus by a certain date" instead of "the upgrade will go into effect when a quorum of delegates support it" in order to provide the certainty of scheduling semantics changes to take effect at a specific date/time.
If we want to upgrade to the same features after the expiration point anyway, then it would just mean the developers would have to release a "new" version of the client with a slightly updated JSON and try again. It is not like these upgrades are dynamic; they require changes to the code of the client and require the delegates (and users) to download the new client.
Yes, this is true. The key phrase is "If we want to upgrade to the same features" -- which is not always the case. For example, if security bugs are discovered before the new feature goes into effect, the delegates can simply veto the new feature.