To date, most of my headless embedded development has been either entirely stand-alone, or has communicated with the outside world via serial.
Serial is kinda old, and getting clunky. Yes, you can use a USB to serial converter from FTDI or whoever, but then you have a USB connection that needs to have a baud rate specified, which is just strange.
On the other hand, USB and Bluetooth both seem to have development models that demand that if you're going to do something new and unique that you spend $$$$$$ to create some new class of device, with vendor ID and all that associated folderol. It's nice if you're building 100,000 a year or more, but not so nice if you're building a few hundred per year.
I'm working on a device that has a need for robust and graceful communication with PCs. On the one hand, data rates are not at all high
-- once or twice a second the thing needs to report that some action has happened, and possibly cough up a measurement at the same time. On the other hand, they need to work in harsh environments that make wired connections expensive, so having them communicate wirelessly is a good thing.
It can't be assumed that these things will have a 1:1 connection with PC's, either -- it should be assumed that up to a dozen could all be at work, funneling data to one PC.
So, if YOU were going to build a device than needed to communicate with a PC in a reasonably robust and seamless fashion, and it was going to be fairly low production volume, and if wireless were desirable but not necessary, how would YOU do it?
If I were to ignore the desired "wireless" part, I think I'd be looking at how the PLC manufacturers network their boxen on Ethernet.