That's a good question. The main issue with having MCUs drive the main user interface, in my experience, is configuration. Especially when it comes to Wifi. Are you planning on it hosting its own Wifi network that the user would have to connect to? If so, that causes problems with connecting to this device and others simultaneously. Are you planning on having this Wifi device join an existing network? How will the user tell it what SSID and key to use? How robust is the auto-reconnection, and how easily can it be reconfigured? Also sometimes devices like this need to be deployed in remote, unmanned locations. How will you handle any necessary port forwarding, firewalling, data logging, remote reconfiguration, etc?
Meanwhile, SBCs with full OSs handle all of those questions with ease, but introduce problems of their own...namely obsolescence. OSs move fast, and many times kernel updates can inadvertently break seemingly unrelated things. Once you develop for a specific version of a specific OS, you oftentimes need to shut off updates and just live there until you can invest the time necessary to update to a new release, re-qualify all of your software and interfaces, etc. Also the hardware itself goes obsolete on a very regular basis. Most SBCs in my experience have a realistic lifetime of maybe 3-6 years. Go past that and it will be increasingly hard to find new SBCs, which means redesigning your adapter board to suit whatever replacement SBC you choose. This is where something like the 96Boards initiative helps, they specify a common form factor, including size, connector locations, voltages, and pinouts, and let manufacturers build to those specs. Theoretically any device you build for one 96Boards-compatible device will plug straight into another one. This helps to fight the hardware obsolescence issue, but you still have the software problem mentioned above.
Personally, if I have a project that can be done on an MCU and doesn't have an interface any more complicated than USB or serial, I'll use an MCU. As soon as the processing requirements or interface requirements surpass that limitation, or it's a device that has a very real chance of being installed in a remote, unmanned location, I typically move to an SBC with a real OS.