That also deletes the record of occurrence, which in most cases is undesirable for audit/tracking purposes… assuming I’m understanding your thought accurately here.
The value to me ending Maintenance early (for some/all targeted host(s)) is that monitoring/metrics/alerting resumes when the “work I was doing in that window” is done.
There are times the “work” could be completed a lot earlier than the scheduled maintenance, and the person making decisions authorises (or wants) to end said maintenance window early as all “milestones” are achieved (so far as one can tell).
In an example scenario where “work” is complete hours early (let’s say it went way better than expected) ending the Maintenance Window early, while also keeping the record of it, means any problems after that point in time can be alerted, and metrics gathered.
In my experience, not being able to end the Maintenance Window early (for some/all of the target hosts) creates a window where metrics aren’t gathered (I’ve witnessed this in some cases, but unsure if it’s reproducible) and alerts don’t happen.
So let’s say the “work” of a project is complete hours before the end of the Maintenance Window, and we “can’t” end it early. In that time, a problem in another area could arise, and alerting would not happen because the relevant host(s) are still in Maintenance. This could tangibly delay any action to said alerts/metrics/etc in an avoidable way.
====
I also want to add, that in my opinion, I’d prefer a way to end the Maintenance Window early for part/all of the host(s) targeted without modifying the end date/time, but if part/all are ended early, add some sort of record which and when were ended early. But keep the initially scheduled end date/time unmodified, so that way any post-analysis can accurately identify “okay so we aimed to end here, but all/part ended here” so future planning can adapt (better planning?), or perhaps uncover other planning issues.
====
Bit of a mouthful, sorry, just wanted to expand on aspects of the value I see here. 