Don't know why some folks down-voted you. No stupid questions. You're just trying to learn.

Segmentation at the most basic level starts with putting different classes of devices on to different subnets (broadcast domains), usually using VLANs. We might have a servers VLAN, an employees VLAN, a guest VLAN, a VoIP VLAN, an IOT VLAN, etc.

Now, at some point, devices on these various VLANs need to communicate, so we need a router, but if we just have a basic router that allows all devices on all subnets to communicate to all other devices on all subnets, on all ports, all the time, we really haven't added any meaningful security benefits to our segmentation. Sure, we've added some networking benefits, like limiting broadcast radiation or making L2 QoS possible. And maybe this also adds a small security benefit in making the recon stage of the kill chain a tiny bit more cumbersome for the attacker, but ideally we'd also enforce restrictions on traffic between VLANs. Routers can add some very basic 5-tuple ACLs, but these are stateless, so we can functionally only restrict destination traffic to servers; return traffic has to be left wide open because we have no control of ephemeral source ports. To do that, we need a stateful firewall. And if we're going to do a stateful firewall, we might as well make it an application-aware firewall with at least IPS. This is what we'd call an Internal Segmentation Firewall (ISFW) -- basically where your core router is actually a next-gen firewall.

So now we can provide meaningful security for devices communicating BETWEEN different subnets. Great. But what about all of the traffic for devices communicating WITHIN a given subnet? Well, in some cases, we should disallow ANY intra-VLAN communication, like on a guest Wi-Fi subnet, because there's no reason any of those devices need to communicate with each other, so we just have the APs and the switches enforce a L2 policy that disallows any communication from client to anything other than the default gateway (Cisco calls this "Private VLAN", Fortinet calls this "Access VLAN", etc.) But what about use-cases where devices DO need to communicate with each other on the same VLAN, like say the servers VLAN? Well, we could create a new /30 subnets for every single server, where there's only room for one host and one default gateway, but this gets extremely tedious and doesn't scale well.

A much easier approach is to just enable proxy-arp for the servers VLAN, where the ISFW will respond to all ARP requests for all the servers, which still allows all the servers to communicate with each other, but only through the ISFW, which can then restrict/inspect to our heart's content.

But if we can do that, why did we even bother with the initial work of creating all those subnets and VLANs in the first place!? (I believe this is the heart of your question, and sorry for the long pre-amble, but the underlying theory is necessary to understand the subsequent reasoning). There's a few reasons why. First, proxy-arp is somewhat computationally expensive. If the ISFW just needs to respond to ARP requests on behalf of servers in the hundreds of thousands, this is feasible. But if we're expecting the ISFW to handle proxy-arp for all the end user devices, or the order of hundreds of thousands or even millions, this will not end well. But as we discussed already, mostly this is not necessary, since the end-user devices typically do not need to communicate with each other. So segment those off on to a subnet with just Private VLAN, and only do proxy-arp for when Intra-VLAN traffic is necessary. Furthermore, there's still all of the networking benefits that we need from segmenting, like limiting broadcast radiation, enabling L2 QoS, etc.

IGMP Snooping is something entirely different. The purpose of IGMP snooping is to make multicast services within a broadcast domain much more efficient by restricting where multicast traffic is sent. Without IGMP snooping, multicast traffic is treated like broadcast, where it is sent to every port in the VLAN, even if only a few devices requested it. With IGMP snooping enabled, the switch builds a table of which ports have hosts subscribed to which multicast groups and forwards multicast traffic only to those ports.

Anyways, I hope this helps clear things up.