To be fair, that is not true. Most manufacturers do not allow downgrades for security reasons. Imagine you had a software release which can be hacked and allow the attacker to control your car (perhaps drive it into the wall of your garage remotely). Tesla patches it, sending out a new release, but allowing downgrades, all the hacker has to do is to deploy a downgrade and off into your living room we go. Hyperbole, perhaps, but it illustrates the point why security typically mandates disabling downgrades. There are other technical reasons too, downgrades also need to be tested to make sure there are no weird interaction, for example your MCU downgraded first but some other firmware in the system is of higher version, now the MCU can no longer talk to this "future" firmware, not even to downgrade it. Also, while upgraded, perhaps some files got written using newer formats, when you downgrade, they look like corrupt files to the old firmware.
Bottom line, downgrades are expensive to support and potentially insecure, hence most manufacturers do not support them. Tesla would have build a new release here with the old source code, then thoroughly test to make sure this "upgrade" applies correctly and does not cause any issues (apparently their process to do so missed this buzzing issue in the first place, so it's not full-proof). It probably is easier and quicker to root cause the buzz and only revert that code, than release a patch, but they may choose to just wait till next release as it may be scheduled soon - famous Tesla service answer "this should be fixed next update, if not, the one after that".
Note by the way that I am not defending Tesla's continuous integration/test on customers release model. While it works for Tesla, it sucks for customers who have to live with issues like that for weeks or months. I am just stating technical reasons why downgrades are technically more challenging than a new release.