I cannot agree more with Eliot_Cole. Example : in case of GraphAPI (design) problems related to Intune, you cannot address it to Intune support because it is not a production issue, or sth that was working before. You cannot address it to GraphAPI "directory" support, because it will land on the EntraID team which has no clue about Intune.
So you end up with recreating your GraphAPI issue with the help of a library (example msgraph-sdk-dotnet), in the hope you will hit same problem, so that you can open the issue in the library or SDK repo (because it is open-sourced code!), and hope the MS guys will repro it and route internally the problem to the right guys. Yes, wrong usage...because no other choice.
I suspect this change is made because it was difficult for MS, to dispatch issues that are closely-related together to different teams, and/or that it is difficult to have internal engineering discussions in GH issues, without disclosing too much details to customers. Other reasons might be because of seeing reports like https://github.com/MicrosoftDocs/azure-docs/issues/108697. Sad... 
(Fun fact : https://github.blog/2020-05-15-remote-work-how-finance-legal-and-it-made-the-shift/ : "I joined GitHub over four years ago as the first distributed team member of the Commercial Legal team [...] One of the cool things about being in-house counsel at GitHub is that we use GitHub issues and repositories as part of our daily workflow, meeting internal clients where they are in their daily workflow.". Does this only work for GH employees?)