Supervision has many benefits besides automatic restarts after crashes. Supervising programs provide a consistent way to start, monitor, and log long running programs. Nginx reinvents its own interface for some of this functionality (like daemonizing, log rotating/compression, conf reloading, etc.), but it's useful for all services to work under the same interface. This is especially true for monitoring nginx's status, where a supervisor like runit is much nicer than 'pgrep nginx' or 'ps aux | grep $(cat /where/nginx/dumps/its/pid)'.
There are some good points there, but they're not particularly applicable to nginx. nginx's relative robustness, its need to log to more than one file, and its need to fork itself in order to perform graceful configuration state transitions suggests that it's not really a low-hanging fruit for robust process supervision.
Besides, its control interface is the same as any other subsystem if you've configured it correctly -- i.e., "service nginx <verb>".
I agree that nginx needs supervision less than most processes because it reinvents many wheels. However, supervision is still nice, e.g. your 'service nginx' example that uses Ubuntu's supervisor Upstart.
I agree it's not worth straining to make nginx's binary upgrade work with arbitrary supervision. However, if someone created a supervisor that solves this problem (systemd), I might give it a try.
