There's nothing wrong with Windows 8 apart from the Metro interface, which is easily disposed of by Classic Shell - in fact Windows 8.1 is a fairly significant improvement on Windows 7 in both security & performance.
Windows 10 has interfaces for touch screen and keyboard/mouse so in theory (along with Windows Runtime/UWP) you should be able to write your app and let Windows take care of how its presented to the user based on the device they're using/their preferences. You can of course choose not to write the app for UWP and optimise it for a single device (eg a desktop PC).
There's some nice additional features in the enterprise (and education) versions - the ones that spring to mind are policy control for auto-encryption of selected data/blocking apps from accessing encrypted data & a lockdown mode (MS call it Device Guard IIRC) which requires every piece of code to be digitally signed by MS or a vendor you choose to trust. If its not signed then it can't run - Device Guard is run inside a hypervisor so the core OS in theory is isolated. It ought to be an absolute godsend for small/medium businesses as it'll stop pretty much all malware (even zero-day stuff).
Win 10 automatically compresses system files - again you have to remember that Win 10 is meant to run on anything from embedded devices (internet of things lunacy) to workstations - which is OK as long as you don't have a SSD as the boot device. One has to assume that MS aren't stupid here as compressing system files would be pointless* in that case so I assume its mainly for hand-held flash-based devices.
There's a lot of Xbox integration which I couldn't care less about. DX12 - meh.
tl;dr not a lot in there for consumers, probably worth the free upgrade from Windows 7 just for the Windows 8 kernel/security improvements, but as always wait for the first service pack.
*Warning - this gets technical & rambles on
Most (all?) current SSDs compress data before they write it, the reason being that it minimises the number of cells written to which enhances performance and increases the working life of the drive. However when you present the SSD with incompressible data (encrypted/already compressed) then the write performance is nowhere near as good.
For example I always encrypt SSDs using AES256 (h/w accelerated in newer cpus) and instead of the manufacturers figures I'll typically get about 40% of the write speed & 30% of the write IOPS. The bottleneck is not the cpu in the machine (that can encrypt 23GB/s), its the physical time it takes to write incompressible data to the extra cells in the SSD.
Why do I do it? Simply because unless you physically destroy the chips inside a SSD (not recommended -seriously don't do it) you cannot be sure the data has been destroyed. Overwrite an encrypted volume a few times, delete it & that's as close as you're going to get IMHO. You can choose to trust the drive manufacturer's "secure erase" function if you wish. I don't
