1) You want to use parts that are qualified to automotive environmental standards, which are more demanding than industrial standards. If you like AVR and ATMEGA chips, you can get those in automotive qualified versions:
http://www.atmel.com/products/microcontrollers/avr/automotive_avr.aspx
If you WANT to move to ARM processors for OTHER reasons ("strong" not being one of them) then you still want to use an automotive qualified ARM processors from any of the vendors that offer the processor & peripherals set and IC package that best fits your needs.
2) ARM processors are available with many peripherals and clock speeds, and with co-processors. But, if you won't use those features, it is a moot point unless the primary reason is to learn about new micros -which isn't a bad thing ither.
3) If you are in an automotive application, you probably don't need to worry about the low power modes (much anyway) of the ARM chips. They will generally still use more power than the AEQ AVR chips, if the AVR chips have enough processing power for your application.
4) It all depends on how well you've written and architected your code! The upper level code/functions should (ideally) require no, or very little modification. Where all the changes are needed are in the ISRs (BIG DIFFERENCES there) and peripherals interfacing.
5) Both NXP and ST have good offerings in this market space, as do TI, ATMEL, and numerous others. I've used NXP ARM chips most often though - largely by chance than intentionally (several times the chips were already chosen by the client for the project). They do differ in peripherals, RAM, flash, and other features. What IDE toolchain would you prefer to use? In some ways, it might be easier for you to stick with ATMEL and their software chain. In most projects, I end up dealing more with th toolchain supplier than the chip supplier for tech support, though I hav had good experiences with NXP. NXP recently purchased Freescale, so right now their tech support seems a bit stretched and running in parallel universes as they try to merge (2) different tech support systems together.