I definitely do not agree with:
The same with MCUs. The first one you use, you're going to like
When I was young microcontrollers were difficult to handle. You had to buy very expensive chips (starting around USD50) which had ceramic housings and a blob of glass and had to put them under UV light to erase them. Alternative were the Eprom based systems which needed some 40+ wires just to get a blinking led because you had to wire up data and address busses and such.
A few years later came the PIC16F84A. One of the fist with Eeprom. Everighing together in a simple DIP package, you didn't even need a crystal oscillator if the built-in RC was good enough. That was the first uC I bought. They were also cheap enough to buy a handful of them, because you know, hobbyists blow things up. I never got around to doing more than a few blinking led projects with the bloody thing. It had a completely abhorrent instruction set (Yeah only 20 or so instructions to learn). What a marketing bullshit.
Then came the AT90S1200, and quick thereafter the at90s2313 and ATMEGA8, which I all bought in various amounts. The internet was also booting up and information was increasingly easy to find. The 1200 was quite limited because of lack of RAM, and the only thing I ever did was to bitbang AN910 in it, which was programming software which interface between a serial port and the SPI bus for programming other Atmel AVR's. Bitbanging a uC in those days was by putting a few wires directly into the LPT port of your PC, and onto a breadboard with your uC. Not very reliable, but enough to bootstrap yourself on a low budget.
My sole reason for turning to Atmel was the availability of GCC for the AVR's. Programming a uC in C that is luxury!
After that I never attempted to even use any microcontroller that is not supported by GCC.
Over the years I've done some 50 odd projects with the ATmega's. and always liked them, and they were fit for my purposes, so for a long time I did not feel a need to learn a new uC family. I briefly had a look at the ATtiny's, but I disliked them very much and quick. Instead of a decent sereal port they have a USI, the I2C (which atmel called "twi" for vague reasons) worked completely differently from the ATMega's, for which I had just written and debugged a nice I2C library. Right then I vowed to never use the ATtiny's again.
Nowadays such hardware implementation differences may be hidden in software libraries, but this was all mostly before "arduino" even existed.
I could start a big rant about all the reasons I dislike "arduino" (no capital there), but I also see it's an easy way to get acquainted with uC's.
Just do not EVER use their half baked java based editor that is not worthy of the name IDE. If you want to start with "arduino" then at least use a decent IDE, such as anything supported by Platformio, or if you're on windows, the IDE that Atmel (now Microchip) distributes. I believe it's based on some Microsoft IDE and people seem to be happy with it.
Advantage of Platformio is that you can easily set up a complete tool chain and it is completely vendor independent. From whatever IDE you use with Platformio you can switch between projects with ATMEGA, ESP8266, Blue Pills, and some 20 or so other uC families. You can also work with "arduino", "mbed", and other platforms. It really is an amazing tool to try out some new uC and it's capabilities without much worrying about how to set up a complete tool chain for whatever uC you're using this week. It just pulls them from the internet somewhere.
A few years ago I decided that I wanted something "new". Nice small TFT displays became available and the ATmega's just do not have the horsepower to drive such an LCD. I do not want to wait to see individual pixels popping up on the screen. Also other projects were growing a bit, and the ATmega's were a bit sluggish or needed a lot of careful programming and interrupt scheduling to ensure proper operation.
Out of curiosity I bought a handful of "Blue Pills" and "Maple Mini's" from China. Significantly more powerful processors, these can update such a TFT with 10 or more FPS which is plenty for a responsive user interface. I fiddled a bit with "stm32duino", a website which has now closed, I believe ST has taken over it's content, and I also fiddled a bit with mbed. It feels like multiple layers of incompatibility libraries thrown together in a bowl and mixed together. When trying to understand the initialization code you find 4 function calls deep an empty funktion with the comment that you can add something there if you want. Yuch. Those 4 function calls should not have been there in the first place. I also really disliked ST's way of first declaring a structure, filling it with some bytes and then calling a library function with that structure, with the end result of just setting or clearing a single bit in a register.
The teensy's may be nice but It's unlikely I will spend USD20 on their development boards. An important factor for deciding for a uC is also the package it's in. I must be able to solder the chips relatively easy on bare PCB's I've ordered. QFP's with a pitch of 0.5mm are OK, but I'm apprehensive of using BGA's. I have never done those, and you can't visually inspect them.
I've always liked to build my own programmers, or use pre-built programmers as long as they are cheap. I thought long and hard about buying an "AVR Dragon", which was about USD80 at that time, but decided against it after reading too many stories of the thing blowing itself up. For the "Blue Pill" you buy USD3 "ST-Link V2" clones and these just work. Even if you damage them, from standing on it, ESD damage or whatever, Who cares for an USD 3 programmer? Just buy a handful of them, which also gives you more opportunities to debug the hardware if you suspect hardware problems with your programmer, you can just swap it for another. I think I've managed to damage 5 or more programmers in the last 30 years, and that is no fun if they cost USD150 each.
I do not like "bootloaders" They are far overrated. Often they are also not user friendly, they take up FLASH, you have to pamper them, often have to press a button to get into "bootloader mode" and other disadvantages. With a decent programmer you have no worries about all those things. Just connect the wires, tell your PC to program your uC and it does it. Always and reliable. Bootloaders can be handy in some niche applications in the field, but for at home on the bench a normal programmer is much easier to use.
I got my first "blue pill" working from a very nice 4 page tutorial from "pandafruits" which explains everything from initialization code & compiling and even connecting with GDB from the command line. It's a very good "getting started" guide.
Another tool I want to mention is Sigrok / Pulseview. Together with an USD 5 Cypress CY768013_something based development board, (or Saleaeae clone) you have a very capable logic analyzer that everyone should learn to use with their first blinking led project on the first uC they ever use. With the "logic analyser" in a plastic box you get 8 channels, with a generic CY7C... board you get 16 channels, but these do not have ESD protection on the inputs. This hardware can sample upto a few Msps and stream directly to Sigrok over USB, so sample depth is not an issue. It is also plenty fast for sampling UART, SPI, I2C and some 100+ other low speed serial protocols. I've even successfully sampled and decoded low-speed USB with it. (1.5Mbit/s) Such a LA is a much better debugging tool then just outputting some bytes to a serial port or printf to an lcd. You can for example continuously output trace information to any un-used peripheral your uC supports. Write "0x13" every time a specific ISR triggers, and another when another ISR triggers, and you can back track timing after your uC program crashed. With a normal debugger you can set breakpoints and halt (which completely destroys all timing) but how do you back track from there to see where it first went wrong? GDB is a powerful tool, but a logic analyzer is a good extra tool to have in your toolbox.
If you read through here you probably thought it was worth it.