While reading a product documentation I came across a line in which they say product supports TCP communication in environments where multicast is not available or preferred.
Why would a company block multicast communication? or prefer TCP over it?
Reference: http://www.hazelcast.com/
"Hazelcast will use multicast for discovery, it can also be configured to only use TCP/IP for environments where multicast is not available or preferred."
Multicast introduces extra overhead for routers in the network. In order to send multicast data, each router has to store some state information about how to reach members of a multicast group. For every multicast group, routers have to maintain some state information. This is why you can't multicast over the Internet in general, it doesn't scale.
So scalability is one reason multicast may not be enabled. Scalability isn't as big an issue for smaller networks, so university or corporate networks may support it. Enabling multicast requires additional configuration for routers as well, and network operators may just see no advantage in going through the extra work to maintain it if there is no need for multicast.
What the site you refer to is saying is that if multicast isn't supported, they can use standard unicast protocols like TCP or UDP to support whatever functionality they provide.
There are some topology scenarios where the only way to run "multicast" is doing multiple unicast replication of traffic and this is generally Not-Recommended(TM).
One example among several. If you have multiple sites connected through MPLS and for whichever reason you need to establish IPSec tunnels between your remote sites and your central site (i.e. because of regulatory requirements) then the only way to do "multicast" among all your sites is doing traffic replication through all your IPSec tunnels. This add CPU/bandwidth overhead to the routers/links and you lose all the benefits of multicast on the first place. (See Multicast and IPSec)
There are some vendor technologies that helps you in these scenarios (i.e. Cisco's GETVPN) but additionally to the vendor's hardware/software support you may need support from your service provider (i.e. in case your CPE is managed by the service provider and not you). You will be surprised the number of times where the hardware and software may support the technology but because the service provider has not a service offering then you are out of luck.
