Out of curiosity, why do you use an explicit semaphore here? I usually used Parallel.ForEachAsync together with ReadAllAsync from the Channel. Avoiding the manual semaphore handling was one of the things I really liked about Channels.
Semaphores work well of course, as long as you don't make mistakes. Probably not an issue in your current version, but can easily happen if the code is more complex or especially when different developers later modify code like this. For example, you release the semaphore in a different class than the point where you acquire it, which makes this a bit less obvious than I'd like. If any developer later adds code that takes a different path this might break, and those kinds of bugs can be very annoying.
It's not really a problem with a simple case like this, but in general I don't use low-level concurrency primitives if there is a higher-level abstraction I can use that fits my problem.