Absolutely, having a service that just listens on port 80 is so much simpler to reason about. I would also add a much easier development setup, as well as deployment to your list of advantages.
That said, having a Go service just be exposed to the wild wild internet may not be a smart idea. Take a look at this issue [1], it is perfectly clear that Go services (relying on net/http) still need babysitting by a competent reverse proxy. It is a case where Go's mantra about simplicity leads to leaky abstractions and just clearly immature solutions.
Also not talking about TLS certs, WAF and other concerns that also may bring nginx etc on board anyhow.
Lol I remember seeing this timeout issue years ago and immediately deciding I would never use Go for HTTP (which is what it was designed for). This makes Go vulnerable to numerous slow attacks and there's no way around it besides "use a proxy".
My guess as to why this issue is left open? Google has global timeouts set on all the network edges so they don't want each service to use its own. Whats good for Google overrides whats good for the supposedly open source project.
This is pervasive in most of their projects. Google open source is like the Reapers from Mass Effect series. They leave some crumbs behind to ensure the software ecosystem develops along desired paths. Not out of charity, they do it to ensure a successful harvest.
This timeout issue is indeed baffling. I believe many Go services out there may have set their timeouts to something ridiculous like 3600 or 86400 as a "fix". Hello slow lori.
Another concern is that the lifetime of a PHP app is rather short, measured in milliseconds. This is actually a rather robust approach. Crashes, memory leaks, all sort of weird states are brushed away immediately to be replaced with fresh state for the next request. Apache/nginx is acting as a supervisor and allowing a lot of shit code live out it's days unnoticed.
Contrast that with long-running Golang processes. You won't get away with sloppy code there, raising he bar considerably. Running a Go executable without a monitoring supervisor is sketchy at best.
I'll be honest, I'm pretty anti-Go. Its filled with hacky workarounds for when various things don't fit their "simple" abstractions. File IO and paths is laughably not cross-platform because of this, for example.
Networking is another example. And casting to interface while the built-in collections secretly use generics.
A good way to avoid all these problems is to use a language with great cross-platform support like Java or C#.
That said, having a Go service just be exposed to the wild wild internet may not be a smart idea. Take a look at this issue [1], it is perfectly clear that Go services (relying on net/http) still need babysitting by a competent reverse proxy. It is a case where Go's mantra about simplicity leads to leaky abstractions and just clearly immature solutions.
Also not talking about TLS certs, WAF and other concerns that also may bring nginx etc on board anyhow.
[1] https://github.com/golang/go/issues/16100