the pins on the usb-c connector are tiny, which makes them individually fragile, but also the connector inside the device is short, and usb-c cables invariably have a long semi-rigid strain relief to protect the cable from breaking, so the cable has a large lever arm to torque the connector off your pcb. it's a huge problem with micro-b jacks, which are about the same size. usb-c fixes some of the micro-b mechanical problems, but not that one

one problem with the usb data protocol is that it won't work over a bus; it requires point-to-point links. but, more generally, my complaint about the data protocol is this. i want two devices with no usb hardware, clocked at 8 megahertz ±10%, with a kilobyte or less of code memory, to communicate with each other. there are multiple reasons that is just never going to happen over usb. usb requires timing precision of ±0.5%, so a crystal or at least a ceramic resonator is mandatory (not a reasonable option on an 8-pin micro), and v-usb requires over a kilobyte of code memory to run at all. and even v-usb only provides a slave device! even if all your devices are avrs with crystals, you can't run a wire between two devices running v-usb and have them communicate. and bitbanging a usb master requires, as i understand it, several times more code (i've never done it)

also, v-usb won't let you do anything else while you're communicating; it needs every clock cycle

so, i want something that's about 3% or less of the complexity of the usb protocol, with timing specs that are 40 times more relaxed

i agree that if you only want power and not communication, and your durability requirements are not high, usb-c is a very practical option. and, even with communication, it's an even more practical option for connections at a larger granularity than what i'm talking about, where the devices involved are big enough for one of them to be a usb master. but that's a different order of magnitude: tens of kilobytes of ram on each endpoint, not tens of bytes