(The problem is exacerbated by the ridiculous fact that macOS includes a 'gcc' alias that is not in fact GCC, and which risks shadowing a proper GCC that the students install themselves.)
I think the track record of Apple on supporting anything standardized speaks for itself (see OpenGL, OpenCL, OpenMP, C & C++ features, etc) - Apple gives as few fucks about cross-platform development as possible. Apple sees its platform being so valuable that developers will jump through whatever hoops Apple puts in their way, and largely their developers put up with this.
I will note here that this vendor lock-in is one of the (if not the) main reasons Apple et al. moved away from the GPLed GCC.
The ability to lock in users is the central difference between open source and Free Software.
As such, this is WAI from the Open Source perspective.
There are a couple of notable examples of major software shipping OpenMP-using code on MacOS, namely R and Matlab, but the structure of these projects means that few of their users have to encounter the complexity of getting an OpenMP-supporting toolchain working. Not so easy for a library author where nearly all of your users will need to use a special toolchain.
Sure, and one of their users could have distributed a version that put it back in.
And GCD is open source (not sure when the source was first made available, though). It even supports Linux (thanks to Swift) though that’s recent.
libdispatch is open source, and available on Linux, but I can't see any reason to use it versus the alternatives of TBB and OpenMP, unless you were trying to port an application/library originally written for MacOS/iOS.
Depending on the platforms you need to support, a more heavyweight but more reproducible solution would be to use a fixed LLVM toolchain, say using Bazel.