Something to consider is how risky releasing a native-only USB product can be. Presumably a mini-size Due would have only 1 USB port. Adding the 2nd port, for a HardwareSerial interface based on the well-tested 16u2 firmware was a very smart move for Due.
The USB software is tricky to get right, times 3 operating systems. Almost everybody takes this code for granted when it works well. But USB is complex. Years ago, I spent many months on Teensy 1.0 to get it working reasonably well in Arduino, and that was after a few months developing the bootloader. Even with Teensy 1.0 in late 2008, the first couple dozen boards had a bootloader bug... one where I sent apologies and free boards. The Maple guys also spent many months perfecting their USB stack. ChipKit went through a painful processing trying to wean themselves off of Microchip's code (I'm not sure which they're using now, haven't looked recently), and so far they're used a FTDI chip as a solid platform for loading code. Leonardo was delayed many months, while difficult USB bugs were resolved. Even Arduino Uno R1 had a couple USB bugs in the 8u2 firmware using Dean Camera's long-established LUFA stack, involving timing of control requests on linux. Even many vendor-supplied USB stacks have bugs, which sometimes go unnoticed because fixed-function products don't hit them, or get redesigned to work around the bug, or very experienced engineers fix the bug (but never share the fix, since it's a proprietary product). I just recently spent about 6 months doing it all over again from scratch on the Freescale chip used on Teensy 3.0, and let me tell you, doing a DMA-based stack is even more difficult. The thought of some previously-unknown USB bug turning up keeps me awake at night....
It's easy to underestimate the difficulty of perfecting a USB stack. When you create a mini-size board with only a single USB connector as the only way of loading code, the software bug stakes are high.