With the current ACPI S0 implementation ("modern standby" in Microsoft parlance) there are a huge set of devices and events which can cause the system to wake. This is in theory a good thing, because it allows the system to perform a lot of background tasks while sleeping and allows "instant" resume in response to user input. It can cause a lot of frustration with "mystery wakes" though. I haven't found this to be especially common on my ThinkPads running Windows although it does happen from time to time, which I eventually tracked down to the Bluetooth controller causing a wake whenever my wireless earbuds connected. Under Linux it's been much more of a problem, presumably due to the Linux drivers having a poorer/less validated understanding of what various device events mean. A frustration is that Linux does not offer as good of tools to diagnose this as Windows does (powercfg). That said you can do a lot of tweaking of the Linux behavior using the acpi sysfs, and on my X1 running Fedora I ended up blacklisting just about every device from causing wake because the USB controller seemed to be generating almost constant mystery wake events.
The short story is this: many devices are now active in a low-power state during sleep and can generate a huge variety of events that the OS is expected to receive and make a decision on. Sometimes the OS doesn't understand the event or there's a requirements issue (implementers did not understand/foresee the use case) and these can both result in the system waking for seemingly no good reason. For example, my issue with Linux seems to be the USB controller generating an event the driver did not understand or handle correctly. My issue with Windows seems to be more that a well-intentioned decision (newly connecting Bluetooth devices should wake up the system, which tends to make sense in the case of a mouse/keyboard) had an irritating implication in real-world use (BT headset that connects to multiple devices simultaneously would connect to and wake up my laptop when I was using it with my phone). Unfortunately the way events are implemented on Linux and I assume on Windows as well, there isn't really any support for "if the lid is still closed the system should stay asleep" and so once the system wakes up for an event, and there's no handler that causes it to go back to suspend, it tends to just sit there awake even though the lid is closed. There's no "new event" for the OS to handle since the lid state remains the same. I'm not sure if it's practical for the system to check the lid state in real-time instead of waiting for ACPI events about it.
For what it's worth I'd say my touchbar MacBook Pro does this more often than my Windows ThinkPads do, to the extent that pulling it out of my bag and discovering that the battery has gone completely flat overnight is probably a weekly experience. I haven't put much effort into diagnosing this so I don't know if it's a result of some odd software I'm using or something.