That is true, however consider the case where someone living in France wants a wake-up alarm at 6am, and boards a plane in Paris that flies to New York. They still want their wake-up alarm to be at 6am, but now they want 6am New York, not 6am Paris time. Similarly, if a DST change happens, they still want their alarm to be at 6am in spite of the DST change. This is all fine if you do your conversion and sleep after the change has happened, but if you do it before, and then there's a change, your Date won't be 6am any more, which is bad.
Even with meetings, which largely don't work this way, there is one case where they do, namely where all or most of the participants change time zone simultaneously. This is comparatively rare, but it is how people expect things to work with DST changes. e.g. if, in January, I schedule a meeting for 4pm London time, then when BST starts, I don't expect the meeting to magically move to 3pm. (Things get complicated if you have a meeting set in e.g. London time and many participants are in Cupertino, since in that case you can't avoid the meeting magically moving in one or other zone because the daylight saving rules differ.)
That's why I say I think we might want an AlarmClock to cater to these kinds of use-case, and why I think we should avoid claiming that UTCClock would be good for alarms specifically. I don't think it is. What it is good for is having a clock whose timestamps can be shared with other software across a network, or saved to disk and loaded again knowing that they still refer to the same time.