I don't think it was a lack of experience with what ARM designs could do. If I were to guess, their hope was that a nominally-familiar architecture would make porting easier for customers interested in building low-end embedded + server/cloud products from the same codebase; i.e. both your embedded client devices and servers would use the same libraries IPC/encryption/etc (same idea that node lets you reuse code between client and server).

Of course the stumbling block there is that the Cortex-M family (rather than 8051, AVR, and PIC generations before) was already designed around good C/C++ support, and the server->embedded code reuse jump is bigger than the work involved in switching architectures. And, of course, the Cortex-M vendors already had lots of experience producing all the microcontroller variants with the particular peripherals their customers want, which is just as, if not more important than the architecture.