A 10 AM appointment is always going to be a 10AM appointment.

And that's why you don't get a lot of benefit from storing it as UTC, when "10 AM" can do just as well. In your example, the recurrence rule would have to take into account the fact that the event is anchored to local time, not UTC, and adjust accordingly. The only conversions required when storing in local time are to answer questions like "has the meeting started yet?" (convert UTC server time to local time and compare).

The original case that inspired me to write on this was actually a scheduled in-person meeting with a publicized local time, so that truly was the most natural form to store the data. I'm really not advocating for all recurring appointments to be stored this way -- there are great advantages to UTC, and it's appropriate in most cases. I was simply providing a counterpoint to the idea that UTC is always the most natural form in which to store times.

One concrete advantage that local time offers, in my specific case, is the ability to refer to a meeting as "the 10 AM meeting" without having to anchor it to a specific date (because it does not depend on the date). This is actually something that is used often in the application I based this example on, and it's not easy with UTC storage.