Sure: it allows us - as developers - to ensure that the thread semantics we expect actually equate with those which are granted us by the operating system, and if we have written well-behaved, multi-threaded code (we have) having the ability to set the AudioWorkgroup ensures that we can continue to organize our threads appropriately - outside the context of the DAW, sure, but … so? Not all DAW’s are equal and having this fine granularity of control over how threads behave in our own local context is very, very beneficial - both during raw development, as well as during the porting process.
Only true while it is the case that the other operating systems have to play catch up with the concept of energy-/processing- efficient cores.
I think the question is, why wouldn’t you want to use an operating-system provided mechanism for ensuring that the heuristics of your threads match the expectations of your users?
As for the discussions regarding feature/development/hacking branches - if you learn to use git properly and already have best-practices in place to do your own local testing, you don’t ever have to deal with these issues. The JUCE team have done pretty well so far - we are on version 7.x after all - so really this is just developers moaning about having to learn how to git bissect when the automatic tests have failed… oh wait, you don’t have automatic tests, and have never done a git bissect? That’s the real problem.