First, there are various ports of the Arduino environment to the NRF51822, but I'll leave that aside for the moment and address using Nordic's codebase or the mbed one.
Generally speaking, one of these paths will put you more in the current "real world" of professional level embedded development, in which the ARM cortex parts play a leading role. You will have conventional multiple source file projects tied together by more ordinary means such as a Makefile or explicit IDE configuration, rather than the rather oddball way the Arduino IDE has evolved to do things. The basic lower level APIs you will be writing against will be much more conventional - ie, your code will start in
main() rather than
loop(), you will generate debug messages with
printf() or similarly styled member function on mbed, rather than Arduino type
println() (though of course you can use
printf() on an Arduino with some setup). This tends to make it a lot easier to port or share code between this and other embedded systems, or even between an embedded system and a phone or desktop communicating with or simulating it. Of course you can treat an Arduino as a plain ATmega and do this with that as well, up to the limits of the CPU and its memories.
People tend to think of the mbed option as being an online "toy" for certain boards, but you can generally use others just by setting it for a board using the same MCU in a similar way. And in most cases you can download a zipfile of a project with a Makefile in it that will drive arm-gcc or a few other compiler choices. The NRF51822 does come in varieties with different onboard storage sizes, and this can sometimes require care and attention to the linker script - in a few cases a project that fits in the online build (apparently with the Keil compilation engine as its backed) will not build in the downloaded GCC configuration unless you adjust the linker script to reduce the stack size, or perhaps change compiler optimization levels.
Countering reasons you might end up keeping the ATmega would be if you need some of its I/O peripherals or its 5v I/O capability. For example, the NRF51822 has limited hardware PWM capability compared to an ATmega so that must generally be done in software.
If you are really at home with "The Arduino Way" switching to anything more traditional may take some adjustment of thinking and habits. On the other had, if you look at the benefits of Arduino being the variety of works-out-of-the-box, easily modified examples you can use to explore the possibility of a project, but often find yourself annoyed by the legacy of its countless quirks and atypical approaches in the longer run, then you'll probably find the adaptation to using the NRF51822 directly to have been worthwhile.