James is correct, you don't need to enable IGMP snooping. (BTW, I didn't write that you did need to enable it, only that it often requires explicit configuration for its activation. Sorry if this wasn't clear.) I also agree it's often good to start without it.
With regard to multicast implementations that "don't bother to send out IGMP membership reports", if they're IP, they should respond to a membership query if they're a receiving host. (If they don't, they wouldn't work with IP multicast L3 routing.)
I wrote "(The latter isn't required for multicast, but just restricts it to the ports that actually want it.)"; latter was referencing IGMP snooping, not the IGMP querier. This might have been unclear, because with IGMP snooping you'll want an IGMP querier. This is often done by multicast enabled routers, but often can be done by IGMP snooping capable switches if a multicast router isn't being used.
James is also correct, it's possible to have other L2 multicast that's not IP. If a IGMP snooping switch doesn't control multicast traffic with IP multicast addresses, but with just Ethernet multicast addresses, he might also be correct that non-IP multicast would stop working with activation of IGMP snooping.
PS:
If the purpose of IGMP snooping isn't clear, it's to avoid bandwidth consumption where it's not needed. If the multicast bandwidth demand is light, it often not critical to have it, but if very heavy, it could be. For instance, if we were using multicast to image one or more clients from a server, every other port within the L2 domain would have to contend with image replication stream.
