Microsoft pretty did say you're holding it wrong.
Apple has always being very clever in the way it 'reports' the current Battery State/Charge. Apple work on the basis that after 1000 full cycles of the battery you should still get 80% of it's charge, compared to new.
I'm pretty sure Apple's Li-ion batteries themselves degrades much faster, but clever software programming by Apple gives this appearance, i.e. initially there is more capacity available than stated, and after 1000 cycles, this "reserve" is gradually added to the reported 'mix', to make it appear the battery is more resilient that it actually is.
It's a tweak Apple worked out over time, with thorough testing of the device.
Now take Microsoft, the Surface Pro 3 / Surface Pro 4 are very different to the iPad, in that these are normal high wattage Intel Processors, they have a much higher current drain / recharge rate compared to an iPad. I think Microsoft firstly didn't allow any software "reserve" and secondly, underestimated the shear damage 1000 cycles of high drain / quick charge rate would have on the battery itself, due to this high current drain.
The so called software firmware fix was never going to genuinely fix the dying batteries in the Surface Pro 3/4. It was the physical stress on the batteries doing the damage. Surface Pros have a 3-4 (more like 2-3) shelf life at most, because of this and people need to thoroughly understand that before purchasing.
Second, when Intel came up with Skylake they added new Sleep / Power efficency states. This relates to similar problems Linux has in interpreting this information from the processor / 'southbridge' io chipset/system bios. It takes a bit of jiggery to get it right. It relates to the low level commands of the ACPI (Advanced Power and Configuration Interface) co-developed by Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba.
The ACPI Interface/code is inherently buggy, but over the years Manufacturer like HP, Lenovo has learnt the workarounds in order to prevent the battery charging problems, while Microsoft obviously have some skill in implementing the next layer (drivers) between the OS and the hardware, I think they were inexperienced in the ACPI layer between the hardware and the Processor, and how this is presented then to the OS.
I genuinely think most of Microsoft woes were related to Microsoft and not Intel, Intel added new sleep/Power States with Skylake and Microsoft rushed out the device based on older interpretations of those sleep/Power states for their implementation of the ACPI/Hardware.
I'd blame Microsoft, no Intel. That's my take.
Intel may have failed to document those Power States properly, but that would be unlike Intel. I think the info was there, Microsoft failed to read it, implement/test those new Power States, it's implementation of the ACPI for the Surface Range thoroughly.
I think Panos Panay may be the fall-guy for this, if they can afford to lose him. He seems very much the man that would try and cover up an issue than ever declare he made an honest mistake.