One critical difference: services.msc isn't actually responsible for orchestrating system startup on windows.
Services.msc is an administrative tool meant for interactive use. It is one of several administrative surfaces for interacting with windows service configuration. The commandline tool "sc" still exists and is still functional, and powershell undoubtedly has a more robust suite of tools for manipulating system startup.
The actual inner plumbing of starting up a windows machine is in some way abstracted from the management surfaces used. For instance, during the Windows XP era, a bunch of work was done on making bootup faster. Part of that work was done by allowing some parts of system startup to happen in parallel that were previously serial.
In versions of windows since XP, other subtle changes have been made to windows startup behavior to positively impact performance. The measure people most care about is how long until you can see your desktop, so some startup services have been moved into Deferred groups if they aren't implicated in giving you a login desktop.
All of these changes have been possible without critically altering the different management surfaces that exist for windows administrators. Service dependency chains, run levels, etc have been in the NT family since early days.
New features show up in these experiences over time; e.g. once upon a time every single service ran as the SYSTEM credential; now there are lots of pre-built discrete identities with different rights to effect some degree of privsep. But these were new values showing up on combo boxes in the existing tooling; not throwing away everything you knew and asking you to start over with something entirely foreign.
One key difference between Windows and rc/sysV is that the latter makes it much easier to promote a random shell script into something the unix startup orchestration knows about.
Windows services have a richer interface contract (start, stop, query status, etc) that is based on C-style calling conventions (iirc). Implementing something as a windows service as a practical matter requires knowing that's what you want it to be before you start coding.
The downside of the unix flexibility is that people ship broken ass shit like Ubuntu LTS where half your stuff is reasonable and half your stuff tells you, "hey, i'm an upstart job! So what you tried won't work any more for some reason that has no fucking bearing on your life! fuck you buddy!"
I got my start on linux in the a.out binary days, and simultaneously worked on Solaris and IRIX machines about 20 years ago. I've added other unicies since then. I'm very comfortable with both rc and sysV. Recent follow-ons like "upstart" have jut felt like hacky shit to me that unceremoniously throws out what met my needs and provides a fundamentally worse experience.
I spent a great deal of time debugging OSX startup a while back (http://blogs.msdn.com/b/mattev/archive/2004/06/21/161770.aspx) and that system was at least sensical and consistently implemented.
If you want the real deal on windows internals, the Windows Internals Books with Mark Russinovich are excellent, and explain the internal kernel concepts and data structures in tremendous detail. System startup is also covered, including the orchestration between smss.exe, lsass.exe, csrss.exe, and all other associated friends.