The purpose of the RobotCore's HardwareMap is to simplify accessing the hardware devices.
Imagine how frustrating it would be if the code had to be modified every time the hardware team decided to adjust the robot's wiring. Why should the code have to change if the wires for the servo controlling a specific operation got moved from port 1 to port 3, or from a port on the Control Hub to a port on the Expansion Hub? The only important aspect, as far as the code is concerned, is that when it needs to reference a specific piece of hardware by name (e.g. the "leftFront" motor) it can call get and be handed back the correct thing.
The HardwareMap supports a design pattern known as a Factory. In real world terms, this would be somewhat equivalent to having a helper to assist you. You say to the helper "Fetch me the key for the shed." The helper wonders off to the box of keys hanging on the wall and searches through it until they find the one labeled "Shed". The helper then brings the key back, or if they couldn't find it in a timely manner comes back and says "There isn't a key for the shed." As the person being helped, you neither know nor care if the helper had to search through one box of keys or several. All that is important to you is that the helper comes back with the key you need.
Another thing that the HardwareMap does to make life easier is that when you ask for the piece of hardware, you can use a more general parent class instead of a specific subclass. For example, you can call hardwareMap.Get(DistanceSensor.class, "frontDistance"). The value returned will be something that inherits from DistanceSensor (meaning it's guaranteed to have a getDistance method) but it could be an OpticalDistanceSensor or a ColorRangeSensor. The HardwareMap itself has done all the hard work of deciding what type of object needs to be created and initialized based on the robot configuration as defined through the "Configure Robot" menu option in the Driver Station application.