One thing is that the materials do not distinguish 'service processors' from 'IPMI' the protocol.
The general facets on service processors broadly are no different than any 'appliance': vendors (particularly cheap ones) are lax about security and updates and there is not a lot you can do about it other than pick a vendor that seems to care or isolate the devices. This is nothing unique to the world of 'IPMI'.
In terms of IPMI, there are things in there that should be and in fact are effectively removed by some vendors today (cipher suite 0, auth none, null user). There are things that can be more complicated and probably should be limited (same username can mean different things on different ports or even the same port but different circumstances). Finally, there is the rather significant peculiarity of the 'password'. The 'password' is really a shared secret, meaning that the target must store it in the 'clear' ultimately. Additionally, the target issues a solved challenge first to prove itself to a client, meaning an unauthenticated entity can get a solved challenge and then offline crack the password if it is simple enough (roughly 1,000 times easier than cracking an entry in /etc/shadow).
So now what to do? Well for one, you should know whether your vendor will share a bmc on it's "normal" ethernet by default. You should have ipmi traffic unreachable by internet systems unless you really know what you are doing (it's not the best long haul protocol anyway). If you can stand it, use random passwords that are unique to each BMC (meaning that an offline attack is rendered futile and a janitor attack can only compromise the system that is already dissected). IPMI can be implemented and configured to be internet-facing secure, but there really isn't a lot of compelling reason to be internet-facing with it. Vendors like Dell, HP, and IBM are more likely to feel the pressure to provide safer defaults than bare board vendors and lower cost vendors.