Systemd changes the way various start up and backgound processes are triggered.
The aim is to come up with something that can do more than the current init / cron et al processes in a more coherent way than at the moment, which dates back decades. Many approaches have been taken over the years, but generally try to keep the foundation of how it works the same, but make it "better". systemd throws out everything and starts over with a different approach.
The reasons why people don't like it are legion. Some because of change resistance - this manifests in many different ways. Some because of the "who" of it. They don't like source of the change. Some of the resistance has a technical foundation - the first process in the current init is very simple and everything spawns from it. With systemd, it is complex, and so the fear is that it has an increased probability of failure or instability. And linux is founded on a reputation of stability. Arguments are that it isn't very unixy - which is to have lots of small tight components that do one thing well all working together. Arguments are that having many processes spawn to do something relatively straight forward is unixy, but that doesn't automatically make it good. Arguments are that having one (main) process mediate all this stuff is better than having everything mediate itself and try to cooperate with everything else.
The difficulty with all of the arguments, is that a significant proportion of them are emotionally based, rather than technical, but all are couched in a technical setting, which makes it extremely hard to really get to grips with the real pros and cons.
I am happy to have systemd on some machines, and happy to not have it on others. With regards to this whole topic, the best bet when you see a discussion unfold is sit back with popcorn and watch either sides arguments dissolve into logical fallacy.