Host group is really nice because of few things. First you can configure anomaly detection for whole host group. So if you have 20 the same hosts for the same application you can always overwrite Configuration for all of them at once. Another thing is configuring alerting profiles, tags, management zones. I like to use this parameter as criteria for configuring those things.
Tags can be configured on host level during deployment as well. They can be used as filters as well so you can in general think on host groups as special kind of tags, but host group is something more because of this anomaly detection thing.
Host groups are defined during the agent install and are used to group a set of hosts based on their purpose e.g. frontend servers and database servers. You probably do not want to have both these host groups have the same threshold limits, so instead of changing the settings on each individual host, you can change the host group settings so that e.g. all your frontend servers have a higher threshold (based on an SLA that you may have). All of the customizations of the host settings can be grouped by Host groups, we use APPNAME_DB and APPNAME_WS for our database agents and out webserver agents as we need to have a very strict database anomaly settings, but are more relaxed with our web servers.
Another use case is to set up Mangement Zones (MZ) to filter the environment if you wanted to focus on one host group in particular. An example of this could be that you want to focus solely on your Database servers without having to see all of the webserver agent data in your environment. You could set a rule for a management zone to show only data that came from an agent with the host group name of APPNAME_DB.
I hope this helps,
ps. Host groups are typically defined at agent install, but this is not required.
Here are some links which may be useful for you:
TIP: I always create a HostGroup tag (definfed at the Process groups level, and pushed to Host and Services levels) in addition to defining the Host Group. This is so I can use it as a filter on views where the Host Group filter is not present, or use it in Management Zones on levels where it would not normally be applicable.
To summarize the other answers and add a few more points, Host Groups:
Control how processes are grouped into Process Groups
Allow for setting Anomaly Detection thresholds for the group
Allow for setting OneAgent Update rules for the group
Allow for easy filtering on certain views (like Hosts view)
Are convenient for use with tags (if you define your naming standard well you can pull out various parts like the Envionment, Application, Function, etc .) For example: Env-App-Function is used as the standard, so we can use regex to pull based on the "-" delimiter.
Are convenient for use with Management Zones (but I would always try to use a tag here rather than the Host group, itself)
In the past, they had to be defined at install time and could not be modified without a reinstall, but since version 1.161, they can be modified using the "oneagentutil" command line.
Example for Windows: "C:\Program Files (x86)\dynaTrace\oneagent\agent\tools\lib\oneagentutil.exe"
They still should be defined at install time, of course.