I do not like the direction Atmel (now Microchip) has been going for some time.
20 odd years ago I switched to the Atmel AVR's because of GCC. It was in the begin days of FLASH uC's. They were also easy to program with open protocols. The first AVR I programmed was with a few resistors hanging from the LPT, to program a better AN910. I like that way of bootstrapping.
Lately it seems that Atmel developed another interface for programming their chips every year, and a lot of it is closed. One of their programmers, the EUR 50 "Dragon" was a fiasco, it regularly blew itself up unless connected to a powered USB hub.
The Fuse settings of their AVR processors are horrible. multiple bits squeezed into as less bytes as possible with weird combinations that change the meanings of other fuse bits.
Then the division between the "mega" and the "tiny" avr's. They are both small uC's for relatively simple applications but their peripherals are not compatible. You can not use an atmega I2C library (which atmel weirdly called "TWI") and use it on a "tiny". Some of the "tiny's" do not have a UART, but some horrible "USI", for which yet another library is needed, and which cost time and effort to get to know it, which is time I'd rather spend on writing real software. I also had a small uC project in which I needed I2C, selected an AVR and then later dicovered that the I2C pins were not slew-rate limited, which made the part useless. Without the limited slew rate, the much faster (but noisier) SPI was a better fit for that project, but needed extra software development time to separate the noise in time with the more sensitive stuff.
The amount of little insignificant differences in the timers is also pretty annoying.
I much prefer to see a description of a timer peripheral with a note in the datasheet. "there are 5 of these timers in this chip".
Then the pinouts. The ATmega328 has 28 pins, but no usable 8 bit port. The only 8-bit port it has is shared with the UsART, which is almost mandatory in each application and therefore not usable. Some of the smaller ATtiny's do have a usable 8-bit port, but then you get trapped into having to rewrite your libraries, which are for the Mega series.
Atmel "maintains" their own variant of GCC for the AVR's. but when I install gcc-avr with apt I get a version that is several years old.
Some of the microchip parts also use GCC, but they've hidden te source for their port very deep somewhere on their site. This does not instill confidence that GCC for the avr's will be distributed in a normal way anytime soon. I really don't want to go to some site, search through some menu structure, make an account or whatever just to download a C compiler with some support libraries.
These overall inconsistencies have added up to the point that I only use the Atmel AVR's I'm already familiar with (and fit my trusty USBasp), and am moving away from Atmel / Microchip for all uC projects those parts are not a good fit.
Over the years I've also killed 4 or 5 of the Cheap Chinese USBasp's. No biggy, just get the next one from the spare parts drawer. This would have been much more annoying with the Atmel programmers, which can easily cost EUR 100 each.
Some of the Atmel programmers also have unnecesarry small and fragile connectors which easily break and are hard to get cables for. Atmel wants EUR 20 for something which should have been a bog standard 0.1" IDC cable. But much worse is having to wait a few days to replace a broken cable.