Because when you figure out how to use them, you can save a tremendous amount of time and energy, and build sophisticated systems with simple code and little effort. When you have the need in a certain area, a lot of them will feel like "Wow, I didn't know that someone could automate this for me with so little effort compared to doing it myself". Most of it becomes increasingly valuable as you operate larger systems with many moving parts.

These AWS services are each solving a separate problem that people encounter, and usually embody a sort of "design pattern" like a distributed queue, or a load balancer, or a cache. Microsoft Azure and to a lesser extent Google Cloud Platform have similar lists of services (many services, each doing a different thing): https://azure.microsoft.com/en-us/services/

It's really just like figuring out any other software ecosystem, though. If you stacked up a list of open source libraries or commercial libraries in a certain area, I'm sure it will feel the same. For example, so you want to get one application to speak to another over RPC. Well, you could use Apache Thrift, or Google Protocol Buffers, or Cap'n Proto, or Swagger.io, or SOAP or ASN.1 or I'm sure countless other things, and that's simply to perform the same task. What if you wanted a message queue? RabbitMQ, ZMQ, IBM MQ, ... I don't know if anyone has tried to put all of these on the same page and product matrix, or even keep track of them.

There's just a lot of stuff out there to learn and take advantage of. Being an effective software engineer in business is just as much about reusing existing stuff as it is about building new stuff from first principles. I'd say it's actually more about reusing stuff, since all other things equal it saves a lot of time. Don't build yourself or manage yourself what you can use for free or buy unless it's your core competency.