ISO 8601 (yyyy-mm-dd)
E.g. if I'm booking a hotel you don't want it to pick up the user's timezone and frob that into UTC to send it over; you want the local hotel timezone. But if you're setting a calendar event you do want the timezone to be configurable, and you can add a picker for that.
Assuming all time fields must have a timezone is why e.g. jekyll will re-date your prior posts (breaking all URL slugs) when you change your timezone.
I suppose. In the product I'm current working, I guess technically we could add a TZ dropdown as you describe, but it'd go unused because the kind of events our users schedule, they want to use their current corporate local time always (there's no travelling across timezones involved for our users), and we need to know what time that is over here, so in lieu of one useful form field (UTC or datetime offset), we'd now have to send two (change the dropdown to a type=hidden), or another one with a "proper" datetime string. I guess not the end of the world[1], but it does introduce more opportunities for bugs.
From what I've seen, few products have that timezone dropdown, and usually it tends to be an override that still needs a sensible fallback, and no information as to what timezone the current user is in gives you absolutely nothing.
DateTime offset lets the application handle most cases, so that's what I prefer to use.
[1]: also needs a timezone