Each target platform has its own quirks and characteristics. Much of this is due to the development history of that platform. For a platform such as AVR, it's fairly coherent, as it was developed by a single company (Atmel) over many years, so it's fairly consistent between different chips and the tools that are used for the platform.
A platform such as ESP8266 (and to some extent its ESP32 successor) was never designed to be used as a generic MCU system, which shows in its rather sketchy and fragmented software ecosystem. Though things have gotten better over the past few years, with various frameworks and open source tools smoothing over the roughest spots, it's a platform where it's easy to make mistakes due to a lack of documentation, issues with tools, and a lack of on-chip debugging.
The ARM MCUs (Cortex-M) are being produced by a wide range of manufacturers in a dizzying number of configurations. Though programming these MCUs tends to be fairly consistent, using tools such as OpenOCD, the peripherals added to each MCU tend to be wildly different between manufacturers, as we will look at in the next section.
Finally, ARM SoCs and similar find themselves in a position similar to ARM MCUs, but with significantly more complicated architectures and fewer peripherals than their MCU brethren. To this, ARM SoCs add a complex initialization routine, requiring comprehensive bootloaders, which is why most people opt to use a ready-made Linux image or similar for the SoC, and develop for that instead.
Here, there's no real right or wrong answer. Most of it comes down to what works for the project, but it's essential that you have a good overview of the hardware platforms you work with.
