My proposal is to have a small exokernel between the hardware and the application. The exokernel is there to provide very simple access to the hardware (like the disk or network) and will rely on the application to do anything complicated (like handling TCP/IP).
So the increased latency of the OS scheduler has little to do with the number of layers between your application and the hardware, and a lot to do about assumptions the OS can make about your code.
You most certainly want a general-purpose OS scheduler, it's just that many applications can benefit from user-level lightweight threads.
I hope I don't come off as a creeper because I was very curious on what you are working on and dug through your comments. Is it this BareMetalOS project?
The answer is, of course, it depends on what your priorities are.
I've seen projects that write OS's from the ground up for a wide variety of reasons (security, correctness, optimization of use case, etc.) But very rarely is it for price reasons.
How is it that you intend to do an OS startup? That's a pretty tough nut to crack.