Since you seem to be polling for opinion, here's my $.02. Whether I'm working on an ARM or AVR does matter (and hence, I do care), mostly based on what it is I'm trying to do. There are use cases where an AVR makes sense, and there are those when an ARM does. In general, there's also a tradeoff one makes between, say, AVR and PIC.
First off, while I'll probably get in trouble for saying this, the "strong contingent in the Arduino family" is something of a vocal minority. Most arduino folk (users) I've come across are the kind who would rather treat their hardware in the same way they'd whip up a python script to do something amusing, often with a lower level of understanding of the intricacies involved than they would have when they'd do "from numpy import foo" . While there is some merit in the Arduino way of doing things, there's also a whole lot of scope for criticism.
I think it's worthwhile to look at the AVRs, aside from the Arduino ecosystem. The Arduino contingent has also benefited greatly from the reasons which made the AVR something of a defacto standard for hobbyist things - a mantle it's been taking over increasingly from PIC even before arduino made its appearance. The AVR's direct competitors would be the PIC and to a degree the MSP430, which is gaining traction owing largely to TI's heavy marketing push combined with its subsidizing tools.
As has been mentioned in other answers, the AVR is the one family which has a clean, standardized way to get from zero to hello world using free tools. The avr-gcc port, the pieces that make the winavr toolchain, plenty of programmer schematics with varying complexity and features but still bound by the authority derived from being supported by avrdude make it much easier than dealing with getting the toolchain worked out.
The PIC's ecosystem is a nightmare, with any number of compilers, programming tools, assemblers, what have you. Many of them aren't compatible with each other. Most of them are paid. Not all of them are good. More importantly, there isn't a defacto standard. The free / open source alternatives (say, SDCC) leave much to be desired, but more than that, have failed to acquire a status of defacto standard like avr-gcc and company have. Even with the software toolchain worked out, you would at the very least have to invest in a programmer of some sort. The PICkit may just cost 20$ or so, but when you have to figure out how to buy it online (Credit Cards, international shipping, forex hassles), it can be a deal breaker for hobbyists. There isn't a good, reliable programming circuit with the standardization necessary to give a newbie the courage to invest effort and resources in getting from the point of finding a source for the IC to the point where Hello World is programmed and the LED is blinking.
MSP430 is marginally better, mostly because its newer (atleast in terms of popularity) - There's much less noise to contend with. TI ships IC samples to you with efficiency I haven't seen anywhere else. mspgcc is in OK shape, and there's even an open source debugging software that isn't hard to find or setup. The problem, though, is that it isn't as hobbyist friendly as the AVR is. You still have the problem of the Programmer, which is more expensive than what you'd need to buy for a PIC. The 3.3v supply operation puts up a percieved barrier to people who are used to 5v Logic. And it doesn't scale in DIP - There are low end ones available, but not once you reach the more fleshed out chips.
Ease of Use
DIP vs SMD, I think, is a more important distinction than it is often credited to be. A DIP IC can be used on breadboard, general purpose boards, whatever they're called where you live, and so on. An SMD IC necessarily requires a fabrication run, or purchase of adapter boards which aren’t always easy to come by in the size or shape you want.
Datasheet quality, application notes, and the readability of them, also, makes a difference. Atmel seems to do a marginally better job at that. Of course, that is a highly subjective assessment.
AVRs can use an internal RC while PICs often don't. They require a crystal, which makes it slightly dicey when combined with a paucity of confidence.
AVRs also seemed more friendly with in-system programming compared to PICs a few years ago, although I could very easily be wrong there.
AVR vs ARM
Your question, though, had to do with AVR vs ARM. Like I said at the beginning, AVR and ARM occupy different spaces in the spectrum. If you've something that you can do with an AVR, then why would you want to do it with an ARM? ARM's are more expensive, require higher part counts, consume more energy, make for more complicated code, need more expensive fabrication processes. Soldering a 100 pin TQFP is more expensive than soldering a 40 pin DIP/SOIC, depending on how you measure cost. This may not hold if you're producing in large volumes and using production techniques friendly with that, but if you are doing that, then the price differential will be become even more compelling to go with the cheaper solution.
As a go-to controller for general hacking around the house or what have you, I'd say AVR's easier to use because:
- More standardized from a hobbyist perspective, more code I can reuse from the internet because there aren't so many compiler variations, and variations between register names and API among family members. (Try porting LPC ARM code to ATMEL ARM hardware, you'll see what I mean)
- Code becomes inherently more complicated (It does. Really).
- The toolchain takes additional work to setup.
- Makes interfacing slightly easier. ARMs would generally drop you down to 3v3 or 1v8 Logic making interfacing to other toys slightly problematic.
- Getting an ARM chip at the local hardware store isn't an option for me where I live, getting an AVR is.