1) Caches are a moot point. They tend to be disabled by default. Just don't enable them. I've never enabled them. Use RAM, especially core-coupled memories for fast instructions and data. Enjoy simple, predictable operation. The caches are there because some people want to use them when developing in a "non-microcontrollerish" style - for example, running a massive UI program from flash - or from an SD card - directly. The caches don't magically mess up your timings when you don't locate timing-critical code and data in cached regions.
2) Getting an STM32 blink an LED requires one (1) register write more than an AVR - 3 instead of 2: a simple enable bit on a well-documented register to turn the relevant GPIO port on. I think the same is true for most ARM microcontrollers. The difference is small: AVR has "power reduction registers" you use to turn peripherals off. STM32 has registers to enable what you need.
3) An ADC on STM32 combined with DMA, while sounding fancy, may be easier to understand for a beginner, since you write about 6-7 lines of this-makes-sense initialization code, and then just read the latest readings directly from the variables - no need to write ISRs to store values and switch analog MUXes.
4) Clock control on an STM32 is not much more complex than on AVR - but instead of calculating some strange separate things called "fuses", which can brick your system preventing reprogramming, you just simply write the config in standard C in your init function. I think this is simpler.
5) With STM32, I don't need a specific programming tool. A standard USB serial cable works.
6) I opened ARM reference manual first time after about 3 years of professional work on ARM MCUs. I have spent about 0.00001% of my time on ARM reference manual, after that. I think I have opened it twice.
7) I sometimes look at the instruction set, and sometimes need to write custom assembly. AVR instruction set is OK, but ARM is very good, simple, and easy to understand.
8 ) ARM architecture is easy to understand, what comes to the interrupt vector table, how the interrupts work, and how to use them. Also register pushing on interrupt entry. I find all this simpler than on AVR, although AVR is quite simple as well. Having prioritized interrupts that can pre-empt others, IMO, makes everything easier. You can write longer ISRs with lower priorities, and make timing critical ISRs pre-empt them; you have more tools in your box to work different ways case-by-case. Using two lines of code to set the interrupt priority and enable it is not complex.
9) I think one of the best points in AVR or PIC is that the existing community mostly develops code in a style what I call "sane". Simple, efficient way. While you can do the same on ARM, it's not trivial because the community is so fragmented, and "everybody" seems to be using bloated ways - dozens of different code autogeneration tools, dozens of different libraries that are complex to use and fail at doing real hardware abstaction - which is understandable, since totally generic (written by others) hardware abstraction is not easy on microcontrollers.
People who have developed for AVR or PIC, often say they miss that "old" style when going ARM. What we need to tell them is: you can go on with exactly that, there's nothing wrong - ARM cores and the peripherals in a typical modern ARM MCU are not that much more complicated than on AVR! It's just that the 1000-line bloated inits autogenerated or copypasted make them look very complex. But if you choose it, you have the freedom to go on in the classical MCU style, and I strongly recommend it to anyone. The problem is, while I'm not alone, our viewpoint won't get enough exposure.
10) Previous point tldr: With AVR, every beginner has a clear and simple route to follow. On ARM MCUs, everybody's teaching different way, it's hard to know what to do, and it often looks difficult and complex - many code examples are long just to blink an LED.
11) Once more: the biggest issue I see on learning ARM MCUs is lack of simple, easy to understand, lightweight examples, and tutorials to do sane, sustainable development.
12) Finally, sometimes a cheap small 8-bitter offers exactly what you need. Use it. Especially, if you are experienced on using the PIC, and don't need the fancy-pancy stuff on current generation ARM controllers, use the 8-bitter to save time. Not everyone needs to learn every new skill. Concentrate on what you find important yourself. Be an expert on something, it hasn't to be ARM.