When I read this, at first I thought "well DUH it doesn't have a desktop OS or various desktop utilities built in, its a microcontroller!"
Then I realized for a lot of people now, their first led blink "hello world" was possibly not on a microcontroller at all. To me, the idea of wanting a mouse and keyboard for a microcontroller to set up wifi seems silly, but to others, they just haven't experienced the alternative.
There is great support for various wifi security standards for the ESP though, you just need to create something equivalent to how a chromecast connects to the internet for the first time. bootstrap an AP, connect to a portal, configure on the portal, reboot and connect to the actual AP.
OTA upgrades are quite useful.
It's not a general purpose PC with I/O tacked on, like a Pi is, but more like the reverse: I/O and a wifi/bluetooth chip that also has a small (but powerful) processor.
The big benefit to ESPHome is it handles all the 'boring' stuff like Wifi updates, timers, and API/MQTT glue code. I still write one-off stuff in PlatformIO, but most of my devices are running ESPHome with some custom code added on, because I don't feel like reinventing the wheel.
Single program and a couple of MB of ram and flash.
Once up and running they really are quite pleasant to use, and pretty damn cheap.
The issues that hurt me the most were:
1/ It doesn't come preloaded with 'AT' firmware, it took me a while to figure this out as well as a PCB respin.
2/ The clearly labelled TX and RX pins are for flashing and debug output only, not for communication with an an external microcontroller. Two to four GPIO pins (decided by the AT firmware) are used for communication in 'AT' mode
3/ Two GPIO pins need to be asserted high and low on startup to enter flash mode. This fine when you figure it out, however the flash tool still tries to upload the firmware and 'fails successfully' with the correct upload delay.
The MVP they use does not always include "as good as our other parts are now".
The ESP is often a good series for that. It is widely used and well tested.
Cubecell is great for very low power. But it took more work to get it working. The scale of use is clearly lower so I ran into bugs at the time that I'm sure are worked out by now.
The result was great mind you. I built a remote controller for some things and it will easily last 10 years on a simple 1/2 as cell.
nrf is definitely more featured and thoroughly tested then either. But the startup can be harder to do depending on what you do (ie running zephyr on it)
When you have an overhead opener the light is built in, and hard wired. It blinks when the door is triggered remotely.
When you have a side mount (jack mount) opener, there is no light built in. They give you a Bluetooth light, meant to be mounted on the ceiling like you would have in an overhead opener.
The light is only required when the door is opened over wifi. All keypads (which are RF as well) and remotes work regardless. It is only wifi opening.
This is not a useful safety device. Either it should be required and trigger regardless of how the door is opened (so that I know that it means door is about to move) or not be required at all. Having it required and triggering only some of the time the door opens is not something dependable or useful.
But if you close the garage door over wifi, the user closing the door could be anywhere. This user may not be able to see the door or warn people nearby that it is closing.
I own a Tailwind device which implements this safety feature.
It seems strange to not at least have the option to choose if you want the light to operate in such cases. The manufacturers have gone out of their way to reduce safety.
Not sure why everyone keeps making assertions about the setup instead of asking questions. First claims that it's a line of sight safety device (which is wrong), now weird claims about physical proximity (which are also wrong).
Zero of the manufacturer shipped mechanisms to open or close these require physical proximity. Someone can open the door while i am in there using the remote, etc. It works fine from 300 feet away, and in fact, it's quite common for it to be opened or closed while someone is 150ft away at the bottom of the driveway.
We also had a wall pad in the house that triggers the garage, also (it's no longer needed but we started with one).
Wifi is no better or worse here - So i still maintain having a device that does not trigger all the time, despite lack of physical proximity, but instead based on whether it's FSK or wifi, is confusing and pointless
It's also more unsafe.
Especially coming from some other board types, it was like "oh i guess that just worked the first time" for a lot of things.
I have a bunch of ESP32-S3's locked in some woodworking machine cabinets (they are used to monitor the machines for dust collection control/failure/etc.). It's trivial to make them do firmware reprogramming over bluetooth. You could do over wifi too, but in my case, the machines are too RF noisy (VFD's, etc) and enclosed to make it work. bluetooth only works because i'm like 2 feet away, but it works and i don't have to open the cabinet to update the programming.
I also use one to broadcast a stupid bluetooth beacon that my garage door opener uses for "UL compliance" - It has bluetooth lights, and it won't let you open/close the door remotely unless it detects them, because UL requires they visually signal the open/close when done over wifi. Which again, just works. I never had that experience outside of the nRF52/nRF53 series
There are some good low-power boards with the S3's, though it can be hit or miss (IE assuming you really want the 20ua deep sleep to be ~20ua).
If you want something like a remote running off a small battery for 10 years, you may be better off with the heltec cubecell's or something. (They really easily get 3.5ua in sleep)