Unlike a lot of the other people responding to this post who are comparing ARM with PIC, I have used LOTS of NXP LPC devices (modern to old). I've also used STM32s, Atmel AVR32s (when Atmel were real) and STR7 devices amongst a smattering of other devices including the TM4C range (formerly Luminary Micro, also used them as LM) and TMS470s and even the... can't remember what it's called, is it MSP430s?
Of all of these (yes even including the TI devices!) the LPCs were my least favourite. Their datasheets appear simple but are so simple they don't include all the information you need. The website is frequently down. The internal peripherals across various families in the range are old fashioned. The DMA controllers in all the devices I used were so bad (inflexible) that it was (orders of magnitude) quicker to not use them! And I experienced issues with RTCs that I didn't expect to experience; I still can't tell you more about those! The driver libraries are also a bit of a pain. They tend to focus on runtime code rather than compile time macros so are quite slow. They're suppose to be relatively common between families but in practical terms, aren't though they are fairly well documented. MCUExpresso is also pretty terrible. I would edge towards Keil or similar alternatives for building code even if there is a cost associated.
So, specifically relating to NXP, I would avoid. ARM is a bit of a leap in functionality but for performance hungry code is worth it. It's much easier these days since the Cortex processors now include the interrupt controller. On the ARM 7s these were unique to each manufacturer! As a result it's fairly practical to write mostly portable application code, even if the low level code isn't easy to port. If your Microchip code is good, that will help.
If you any up with more specific NXP questions, I will try to do my best to make a comment.