I think it's just largely perception amongst the anti-systemd crowd. Systemd is a virtually unmitigated boon to Linux, but some people fear its relatively tight coupling and lack of adherence to some platonic ideal of the "Unix Philosophy". Indeed, systemd's design is inherently epicurean; the aim is to create a unified base system for Linux that reduces friction and makes people's lives easier.
"Turning Linux into Windows" is hyperbole, though; the most used and developed-on non-mobile Unix -- Mac OS X -- is similarly epicurean, and blithely makes use of tightly coupled components designed to work together, to deliver a smooth easy-to-manage experience. And it's eating Linux's lunch.
Yes, there's a bit of hyperbole in that statement, but there is a problem there. Pottering has pushed a very "our way and no other" attitude, even when other people have requirements that aren't met by systemd.
Worse, the tight-coupling between components is a perfect example of the "embrace and extend" tactic. The monopoly position systemd currently enjoys has successfully been used to extend into a disturbing number of other components[1].
As for unix-vs-windows - switching to a windows-style binary log and rewriting an inetd into a mandatory "SvcHost.exe" for linux is bad enough, but the real issues is the removing of well-defined barriers between components.
Pottering's hatred scripts is a problem, because using scripts as the "glue" in unix is one of the most important features of unix. Keeping many of the the interactions between components in an open and readable format has forced developers to create (and deal with) methods of API that can actually be extended beyond the original project. Systemd returns to the windows style of just making function calls into the current implementation. Being forced to, for example, listen on a unix socket for a command works easily with anything, even into the future. Requiring that same message be sent by calling some function encourages linking to extra libraries and makes interaction from scripts much more difficult.
This isn't about any technical benefits; keeping the IPC between components open and well-defined is even more important than access to the source code itself if we are to maintain an ecosystem of Free Software. For those of us that would like to have a Free (as in freedom) Software ecosystem survive the current War On General Purpose Computing[2], the campaign by the pro-systemd people is, frankly, terrifying. Sometimes there are more important goals than "faster" or "cleaner API" or "easier to write". Keeping the OS - both the kernel and system-utils - open, free, and interchangeable needs to be a high priority goal, or we will lose the progress the Free Software community has made over the last ~decade.
Could you give a little more background about this? (True curiosity, I don't doubt that what you say is true!)