I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.
(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)
I'd say at the 150 or so developer mark, we should start talking about scaling (adding a second Geo node for failover at a minimum) or if you need more robust uptime requirements, going towards a more active-active distributed cluster. I use the word "distributed" and not "highly available" as we like to find the right fit for each org. Some orgs need true HA, and it takes something close to ~30 servers to do it. Others, just can benefit from some web frontends, and separating out the DB layer, and potentially traffic shaping to separate CI load / User load.
I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).
I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.
We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.
Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)