In applications, the PIC32MX is just as good as any ARM M0 or M3. Unfortunately the powers that be have chosen to take a rather bizarre direction in the software support, using excessive abstraction and unnecessarily implementing a proprietary software framework more at home with a heavy weight OS than a microcontroller. Luckily on the MX series the old MLA library is still available but is deprecated, although it's an organically derived mess. The new MZ devices pretty much force you into using the new framework.
That's why I never use vendor frameworks. Ever. It's just not worth the pain and hassle. I'd rather take the time to write my own. Then I know it's done right.
Are you really sure you want to write your own USB and Ethernet stacks?
Usually the USB and ethernet stacks aren't vendor provided to begin with. But for simple peripherals like SPI, UART, CAN, I2C, GPIO, timers, etc, etc you are far better off writing your own or using field-proven code from third parties than to rely on the vendor provided libraries.
Yes, but I wasn't talking about SPI, UART etc, I was specifically addressing complex peripherals like Eth and USB. I absolutely agree that there is a lot to be said for using your own code for driving simple peripherals. Most APIs for simpler peripherals are barely fit for purpose, trying to be jacks of all trades and masters of none. And at the end of the day, you need to understand how these simple peripherals work to use them, and using someone else's crappy abstraction isn't going to help you very much. Not to mention when you want to start using DMA with them.
For Microchip eth and USB are vendor supplied, I can't imagine even contemplating writing either stack, far better for my sanity and efficient use of resources to buy it in or use the vendor-supplied stack, at least you stand a chance spending time writing your application and not a protocol stack.
Even if you use something like LWIP, someone's still going to have to write a driver for it and manage both the on chip eth and external phy. While the external phy isn't too bad, I'd not be too keen on writing and debugging the eth driver. For USB, well, I wouldn't even want to start marrying up a given physical interface and come up with an API.
Regrettably Microchip have pretty much forced the use of their Harmony software framework now on PIC32MZ if you want to use the integrated Ethernet or USB. With it, there's a whole steaming pile of abstraction to learn. But as you need to understand the simpler peripherals anyway to use them, why would you want waste time learning the shortfalls of someone else's abstraction when you could've written your own?
In the end I am in agreement with you, but I was specifically raising what to do about more complex peripherals. Sure, you could buy in a Lantronix adapter or similar, but for medium to large volume price sensitive applications that's not commercially viable. FWIW, the same applies to the use of FTDI chips in the USB space: they're an expensive peak in the BOM, so I avoid them for anything other than small volume stuff.