I can obviously not speak for the developer of LOOT, I can just give you my opinion:
a) imho YAML is a good choice. Compared to json it's very readable to non-techies and it requires less escaping for special characters. One can argue over whether YAML or JSON is harder to break - yaml depends on indentation, json will break if you miss a comma anywhere or have one too many - either way you will want a validator to ensure the file is valid before it gets committed.
The INI format is not simple, it's very deceptive. There is no standard for ini and different parsers may treat files differently in regards to stuff like character encoding, multi-line entries, comments and so on.
The perception that ini is simple is very problematic. BethINI for example, a tool for configuring fallout and TES games technically corrupts the ini files for some games it configures because its ini file library treats multi line entries different than the game.
99.9% of the times users will not notice because the entries it corrupts are irrelevant but that's luck more than anything.
b) github gives you free file hosting, version control repositories supporting thinks like branching and everything, all of which makes the service more powerful (e.g. when LOOT changes its masterlist format it can host them for the old format in one branch, new format in another without breaking anything). There aren't that many services that do that.
Compared to other version control services github is super easy, so the alternatives are either a way more complicated service or a way less powerful one.
Besides: It's not like users have to use git to propose changes to the masterlist, if you're scared of git, you can just post a message in the issue tracker and someone more comfortable with it can add it.
c) What will happen when: mod C needs to be placed after mod B, mod B must be placed after mod A, mod A must be placed after mod C
This can never happen. It's possible to set up (user) rules for such a cycle but LOOT will refuse to sort in its presence but you will never have a situation where it has to be set up like that. The end result always has to be a sorted, one dimensional list, no matter how you do your load ordering. A cycle would mean that the same plugin needs to be in multiple places at once.
d) Let's assume that the same mod can be installed into 5 games
It's very rare that one mod (with plugins no less) can be installed in multiple games, I'm not aware of any case where a plugin works with more than two games. And then you will always want separate load orders per game.
It's true: There is a good chance that if you have two mods that need to be loaded in a certain order they need to be loaded in that same order across all supported games but the effort to account for that is not worth it.