If you set 2.4GHz to 40MHz wide channel, 20MHz capable devices won't connect? Are you sure?
Well, not observed here on any of my 6 networks, business and home, using different equipment.
Honestly I've never once tried to set 2.4Ghz to 40mhz in a permanent setting, just for brief testing and the clients were all 40mhz capable. Even if I was in the middle of nowhere (and thus not concerned with being a jerk to the neighbors), it is just asking for as much interference as possible. By the time 40mhz 2.4 came around 5ghz was plenty common. Given the decreased range of 40mhz 2.4 vs 20mhz I really see no reason it was ever released, 5ghz is better in pretty much every respect. Once you get beyond the usable range of 5ghz, the 2.4ghz 40mhz is having issues as well, likely running slower than 20mhz would be.
Again what the GUI (or CLI) shows and what it is translating that to in the hardware may be two totally different things. I've got an old Ubiquiti N outdoor AP that claims to have CCK data rates disabled but the radio in that particular model ignores that command. So I have to manually set the minimum data rate and beacons to 12M if I want to totally disable CCK (which also disables the 6M N rate but that is fine with me, don't want a client with that poor of a connection able to connect anyway).
As far as this case, the intention as it was always presented to me was if you hardcoded a channel width, only clients supporting that same channel width should be allowed to connect. I've seen that happen in practice, but have not tested it with any home routers, which I've always left set to 20/40/80 without any issues. My laptops both support a max of 866M (dual antenna, 80mhz) and I can push 450+ consistently over that which is about the most you can expect, so saw no reason to toy with it at home. There is very good reason to disable 2.4ghz 40mhz and 5ghz 160mhz (or even 80+80) and I always do that, but beyond that, haven't seen any need.
Now, are hardware vendors required to adhere perfectly to every aspect of specs and standards? No. Cisco for one is known for ignoring (or creating their own) standards constantly. In their APs you can either hardcode the width or select "best", which is an algorithm that picks a width based on the number of clean adjacent channels available. In that mode, from what I recall it also allows clients with lower width than what it has selected to connect, sort of a "compatibility mode". I'm sure some other vendors (possibly Asus/Broadcom it sounds like) have followed this model. When hardcoded, my colleague and I did notice it behaving as expected, only allowing clients supporting that exact width to connect, so in that case it appears they actually were adhering to the standard when hardcoded. Maybe they've changed it in newer code, this was back when AC was much newer.
All I can say is I have tried, and when hardcoded to 80, N clients (two different Intel chipsets, possibly their implementation is the one that doesn't play nicely with it) could not connect. Change to 20/40/80 and they connected right up at 40. During that same session, my phone which is AC saw much decreased range, and while I didn't specifically look to see what channel width was in use, my assumption was that it was not able to fail back to 40 and 20. This was on a Ubiquiti AP. As mentioned, similar results were seen on a Cisco AP. No MCS rates were changed or other things were tweaked other than the width for that test. Not really unsurprisingly, 160mhz outperformed but only very close to the AP, at further distances 80 hardcoded was best, but changing to "best" (20/40/80) which selected an 80mhz channel but allowed for 20 and 40 was slightly worse but not by much. This was in an environment set to mimic an office with various client types and noise.
Regardless of all the above, since the post I replied to was about a client that could not connect and the user had hardcoded their channel width, and was looking to increase compatibility/interoperability, the suggestion to not hardcode the speed made by another user is a valid one.