At various points, your project is potentially 1.5 weeks late or 4 days early. Your methodology values calculated variances, but (as far as I know) doesn't mandate continuous re-planning. It would therefore be more efficient to value communication over re-scheduling.
Communication: The Underlying Question?
In your question, you state that at some point in your project you think you're 4 days ahead of schedule. Awesome!
Then you ask some detailed sub-questions, currently tagged with schedule-risk, but really about how to communicate your project's status to a wide audience that you've defined as:
Multiple audiences: stakeholders of the project, project sponsor, senior management, public, the project team itself as it is managing the project and its health....
To my way of thinking, all your questions boil down to How do I communicate that we're slightly ahead of schedule?
Favor Communication Over Re-Scheduling
1. Do you alter the durations of the remaining work packages based on your latest revised estimate, allowing the schedule to calculate a finish that shows the favorable finish variance?
In other words, should you recalculate your schedule with accelerated dates, removing slack from the process? That seems like a bad idea. Slack is important, regardless of one's chosen methodology.
2. If so, do you process the change in duration through your change control or do you consider duration something outside of what is baselined?
Change control is usually a process for adjusting scope, not recalculating schedules. While there is some inherent overlap in that scope can impact scheduling, I don't think submitting positive scheduling changes to a steering committee for approval makes sense.
In this particular case, I think what you'd want to do is provide a communique saying that the project has is slightly ahead of schedule (yay!) but that at only 30% completion this slack may be required to mitigate other schedule risks down the road. This has the dual benefit of keeping stakeholders informed while protecting necessary slack from reduction by management fiat.
3. Or, do you keep your original baselined duration the same and show in another way your latest revised estimate and the resulting finish date? If so, how?
Again, communication is the key. Your original baseline is used to calculate deviations that need to be controlled. Slack probably doesn't need to be tightly controlled, so unless your project goals have changed dramatically there really isn't much justification for a new baseline. A new baseline also implies the need to review your project controls; is that worth it for this use case?
Instead, your routine status communications should highlight the process efficiencies that have provided this slack. You might also want to identify project risks or milestones where the slack can be allocated to mitigate slippage in the future, but that may not be a level of detail appropriate to every project communication plan.