You are asking for an answer from a security point of view. However there is more than one security point of view depending on which threat model you have in mind.
If your threat model is an attacker attempting to compromise your server by making requests to your server, I would say it doesn't make any difference how you handle requests specifying an IP address in the host header rather than a domain name.
It is very unlikely that your updated handling of requests with an IP address in the host header would open you up to any new ways of compromising the server. And compromising attacks against the full application on your primary domain name would work regardless, since the attacker can just put that domain name in the host header.
If your threat model is an attacker trying to lure your users into a trap by giving them links to unofficial domain names pointing to your server, then remember that an attacker could achieve the same by setting up a proxy on their own IP, which modifies the host header before passing the request to you, and they could making any changes to the replies before passing them back to the user.
As such there is no significant risk in this area either. Unless the attacker is attempting to perform a phishing attack. The best you can do to ensure that users don't fall for a phishing attack is to only have one legitimate domain name they need to be able to recognize. Redirecting all requests with an IP or a secondary domain name in the host header to the legitimate domain is a user friendly approach to this.
However it may be a tad too user friendly. After all, the users aren't supposed to be coming through a URL using IP or secondary domain name in the first place. So the redirection might lead to a situation where insufficient attention is given to URLs not using the proper domain - because they "just work". If users get used to a variety of domains and IP addresses being used in URLs, those users will be an easier target for phishing.
Having the secondary domains and IPs all produce an error message which includes a link to the proper domain may help ensure that both users and developers remain aware that URLs are supposed to contain the primary domain and nothing else. Serving the error pages with a proper 4xx error code would produce more predictable results if any automated software is accessing improper URLs. However serving the error pages with a 200 code might make it easier for search engines to find the content in case of external links outside of your control, which happen to point to the IP or secondary domains.
Regardless of whether you go with 2xx, 3xx, or 4xx code for those responses, the cleanest configuration to achieve it would be a separate vhost in your webserver configuration. A previous answer gives an example of how this could be achieved. Other webservers can do it as well.
Another threat model to keep in mind is requests to your application trying to trick your application into using an incorrect domain name passed through the host header in dynamically generated content. If the domain name from the host header is only used for generating an answer to the request which used incorrect host header in the first place, then this is not a major concern. However if your application use the host header for generating URLs that will later show up in emails or in your database, then this is reason for concern.