We use the same scripts to run stuff on our cloud: we have a layer of init scripts on top of m2ee-tools to restart on server reboot. Additionally, you can use m2ee as either a lib or a CLI to talk to the mendix runtime, asking for statistics or to perform a Health Microflow (which the devs can configure in the modeler). This should allow you to do all the monitoring and sysadminning you want :)
As to your question to run directly under supervisord or systemd: I don't believe we have support for that OOB, in our infrastructure we've always run with init scripts that need to grab config from an external source anyway, so we needed some custom layering there.
I'd probably suggest you do one of three things:
Well, actually m2ee fullfills a similar role as supervisord does, except it backgrounds the process, writes a pid file and then connects to the admin port to configure it and fully start the application (you can see that happening viewing the trace logging when doing m2ee -vvv), (the pid file is actually only used as a backup to be able to kill the process later if the admin port of the JVM gets unresponsive).
Starting m2ee from supervisord is like starting supervisord (or start-stop-daemon) from supervisord. It does not really make sense. supervisord is meant to be used with dumb processes which do not implement backgrounding, and do not close their stdin/stdout when they start.
m2ee is also designed to be used by an unprivileged user account instead of being started from init scripts or supervisord (that's what customers ask for, they want to have a tool that does not require their application development team to have root access), and that's why it does the double-forking-backgrounding itself that you would otherwise do from an init script or systemd.
I think it would be possible to rewrite m2ee so that it would not exit the intermediary process in the double-fork and keep the process group intact, while still running the second part of application initialization in the first process (which is attached to supervisord), but doing so sounds a bit like the work needed to make supervisord run in supervisord itself. You'd have to make the whole process group work correctly with signals (so supervisord stop does not just kick away the m2ee process and leaves the JVM running) and stdin/stdout behaviour, which will get messy. It's certainly fun to try, but I never did before, because it was built for another use case, namely that the user account that has to control the application is always an unprivileged user account.
The ideal thing for supervisord would be to start the JVM process directly (instead of having m2ee in between, which has the same purpose), but in that case you would have to know the exact environment and command to provide (and figuring that out is exactly what m2ee does) and afterwards implement something else that connects to the admin port and does the second half of the start procedure (which is also what m2ee is doing for you).
If you just want to have the app started again after reboot, you can put an @reboot m2ee start inside the crontab of the local user account. Sounds dirty, but it does the job. Stopping can be implemented by calling m2ee -y stop as the user account, which will first try to shut down the application in a nice way using the admin API, and if that's not possible because the JVM is heap spacing like crazy or got unresponsive for some other reason it will resort to sending signals like SIGTERM/SIGQUIT to make it stop in a "not nicely" way.