There could be a zero day in the http/https service too...
Which runs as an unprivileged user, with privilege escalation mitigations in place (e.g. separate namespace, or SELinux protections etc.) which aren't practical for ssh when used for remote administration.
There could be a zero day in the firewall...
Sure, but your firewall doesn't have any open ports facing the internet, so now we're talking mainly about kernel vulnerabilities. Better to have firewall appliances on separate devices running a different kernel/OS in addition to host-based firewalls on your web servers, so that you have some protection while one has a vulnerability.
There could be a zero day in whatever vpn service you use instead of direct ssh access...
Zero day vulnerabilities can be found in anything, you always have that risk.
And that's defense-in-depth is important.
Note: I didn't say to not implement key-only auth (possibly restricting how authorized keys are deployed), it is useful, but not always sufficient.
I have fewer devices, so the overall likelihood of a zero day that affects me being discovered is lower.
Plus if you were to gain a foothold on the network, you would see the exact same services that you see from the outside so it wouldn't get you any advantage .
In secure networks I have designed, this was not the case.
Hiding things behind firewalls makes people complacent and they leave all kinds of poorly configured or default services present on the assumption that they're inaccessible.
That's a possibility, but not necessarily a certainty.
I would typically have a monitoring agent installed on all servers, which would alarm on any unplanned ports listening, to mitigate this (among many other controls, such as host-based firewall rules, auditing etc.).