Otherwise, I'm not really sure what this offers that alternatives don't, apart from the -a 1 2 3 -> [1,2,3] business which seems highly confusing and undesirable to me so I'd think of it as more of an anti-feature.
I think my only real point of "frustration" (mild at best) is that flag composability isn't always possible (eg embedding/sharing common non-root flags across flag structs), IIRC struct tag eval doesn't reach nested types.
Other than that though, it's one of those nice libraries that just does a thing and gets out of your way.
TBH I rarely do it much anyway, mostly the flag struct ends up being one anonymous struct which is operated on in the main package only. I do like writing custom types for parsing though - I've seen engineers do a bunch of post-hoc parsing logic which generally just ends up being messy.
What compile-time validation do I actually lose by using struct tags for CLI arg parsing?
Beware of microbenchmarks, but in my tests the above package only added around 0.001 ms over the standard library flag package. Even if real world usage increases that by several orders of magnitude, it isn't going to matter. No human will ever notice.
Anyway, I think you're overstating how hard reflection-based code is. Yes, it is tricky and should mostly be avoided, but it's not beyond the scope of human intellect to understand (especially Go's which is pretty sensible).