Certainly back in 2019 the Native API had failings - including that it didn't play nicely with deep_sleep; but in the last 7 years an awful lot of work has been done to improve many aspects of ESPHome.
In my "Notes on ESPHome deep_sleep" thread (which you referred to above), I even recommended MQTT in March 2025 ... but then by August 2025 I played with the (then new) HA Input Helpers and showed in post 9 how HA Input Helpers and the Native API achieve the same result. Also the ESPHome 2025.6 update included Native API Speed Enhancement, which I expect was mostly "Replace API deferred queue with efficient message batching system esphome#9012".
I now recommend Native API especially for new users, unless there is a particular reason for using MQTT.
As for "Native API is totally driven by the HA controller" ... I'm not sure its that simple. I understand that Native API running on the ESP32 device does operate as a server, so you are probably correct - but that suggests that HA is regularly polling the ESP device, and there would be a delay between polls to avoid flooding the network. Yet, looking at the logs during boot, I have never noticed that sort of delay between initialising the Wi-Fi and Native API communicating with Home Assistant.
Other users have commented that Wi-Fi is a significant power drain, and so the less often you are firing up wi-fi to communicate (whether over MQTT or Native API), the better your battery life. I have certainly noticed this with my greenhouse ESP32.
I have also seen discussions that ESP32 chips are often chosen for their low power consumption - but that is the chip itself, while the development boards and other electronics are still powered on while the ESP32 core is asleep ... resulting in disappointing real-world battery life.
There have been several remedies suggested, including disabling the Power and other LEDs on the development board; and turning off power to the i2c and other buses (effectively turning off the sensors) while the ESP32 is asleep. These issues are not unique to the ESP32, but may be an effect of developers trying to add more "useful" functionality to the recent development boards without properly considering power & deep_sleep ... in which case a more basic ESP32-C3 would be better than an ESP32-S3 with lots of extra features.