There may be more security from the game logic server, if you don't give it an external IP address, so it can't be found at all on the internet.
However, if you have a hole in your relay server, then that hole can be used to jump into your network, and from there, a determined attacker can then get to the game server, and if the game server is not hardened like it would be if it were exposed to the public internet, you're in more trouble than you might be if you considered the game server as public.
Also, there is the cost of running three servers instead of two.

For a small game, OR for a game where "seamless server transition" isn't necessary, I'd rather just expose the game servers directly than use a gateway/proxy/relay.
Fewer things to go wrong.

How would I go about 'Hardening' the host server?

In theory, hardening is a simple mixture between good configuration, good software, and good operational practice:

- Don't run any services you don't need to. Typically, this means just running a SSH server and your specific game server. Other services, like a local caching DNS server, is generally not a good idea!
- Don't allow connections to management interfaces from the greater internet. For example, if you have a private network, don't allow SSH connections from public addresses, only from private addresses.
- Enforce access rules both in configuration files (assuming your servers have configurations for which addresses/interfaces they bind to) as well as using host-level filtering (iptables on Linux, Windows Firewall on Windows.)
- Be fast about patching as soon as security updates are available for your OS and for servers you didn't write yourself.
- For software you write, make sure that you check the size and validity of each packet. If a field of a UDP packet says "there are 312 bytes of user name" but you only received 270 bytes total, that's a bad packet. Beware signed values (char is signed and may be negative!) and test all code with all extreme edge case values.
- Religiously read the logs from your server. When there is a new kind of log message you haven't seen before, research what it is and why you see it. Classify log messages into exactly two classes: "can be ignored at runtime, but useful for post-mortem debugging" and "needs human attention pronto." If some log is not useful and doesn't indicate a problem, AND you know what it means, then configure/filter that specific message out.
- Keep a constant eye on metrics such as CPU load, RAM usage, network ingress/egress, CPU temperature, disk space, disk I/O rate, swap usage, and so on. Set alerts when they fall outside normal bands.
- Inside your private network, still enforce access with SSH keys, use TLS where possible, etc. Only allow cross-host connections that make sense. For example, if you have application servers, and game servers, and database servers, the game servers should not be allowed to access the database servers, but should have to go through the application servers. Enforce these rules with network filtering. Another good example is SSH command line access; typically you have a "bastion" host that you can SSH into, and SSH to other hosts is only allowed from that host and some spare/backup host. SSH directly from a game server host to an application server host would indicate a non-standard use, which should be disallowed.
- Keep track of what traffic you see internally. If there is a new protocol or new pair of hosts talking that you haven't seen before and don't expect, alert and investigate!

When you actually get to implement this in practice, you will find that certain practices or requirements will conflict -- maybe the ability to quickly patch servers means that your servers need to be able to SSH outside of your network to grab those patches, but you don't generally want to allow SSH out from the servers to the greater internet. Or maybe there is a traditional "features versus security versus schedule" conflict. How you deal with those determines your culture.
I can say that starting to do these things early is, in the long run, much easier than trying to come from behind later. If you have a mess of internal connections and millions of unaudited log messages per day, trying to bring order is a massive undertaking. On the other hand, if your game sucks because you spent all time on hardening and not on gameplay and polish, then all that hardening work was wasted (other than as a learning excercise.)

For added security, would you recommend I only install those modules and dependencies I'll be needing, maybe this is a no-brainer, but I'm just making sure it's worth the extra hassle?

If you can get away with having less software on the box, then you should! Less to break, less to use for an attacker, less to configure/manage/upgrade.

The risk of having a module installed, but not used by your program, is small, but not quite non-zero. Specifically, if an attacker manages to inject code that your Node process runs, AND one of the installed-but-not-used modules have a security hole, then the attacker could load that module and use it to try to break out of the Node.js process. This is somewhat far-fetched, but, as I said, non-zero risk. Whether mitigating this risk is worth it depends on how expensive it is for you to not install these bits, and how bad you think it would be if this risk ended up in a problem.

Security isn't really a "100% all the time" thing, anyway. The most secure computer is the one that's turned off and locked into a vault with no contact with the outside world. To actually get value out of the computer, you must lower those defenses, and the return on investment calculation is "how much return will I get by doing this, versus how much exposure do I add, and how bad would it be if that exposure got exploited?"