
I'm not a SP expert but if you read that article completely I think it stands out why it won't work. Firstly the .NET devs are correct that we generally use a single site for both HTTP and HTTPS. This makes sense as it is literally just a binding. Furthermore we can add multiple host header bindings to the same site. Often we will set up an HTTP redirect rule to bounce anyone using HTTP to HTTPS. This can all be handled in IIS because ultimately our app doesn't care. Hence keep it simple.
But this is SP that you're talking about and it doesn't work that way at all. In the docs you posted it specifically states that the typical approach to changing bindings and whatnot won't work with SP because internally it is managing stuff that relies on that info. Hence you'll get broken behavior if you simply configure things in IIS like you would a normal site. Therefore, while a single site is preferable, it won't work with a site that is tied to SP and hence you should use multiple sites. The reasons are given in the docs you listed and are related to SP's internal configuration data. I believe the gist of it is related to SP generating links. Unlike a traditional site where we can bounce you from HTTP to HTTPS and keep you there SP might bounce you back and then you get the security warning from the browser. That would be confusing to the user.
Of course this is only for sites that actually are hosting SP and not just all sites in general. I don't know why your devs would care about this though as SP would be something I would expect your networking team to set up for a company. The devs might build SP extensions (but they wouldn't care about bindings and whatnot) or perhaps point to SP URLs (also wouldn't care about bindings).