I'm never short of an opinion, that's for sure. 
If you do want to go that route, maybe have a look at uibuilder. That lets you host your web app in NR and facilitates the comms for you.
Whether to use NR at the centre is mostly a decision as to whether you are able and willing to code any business logic in a node.js app using code rather than in NR (which is a node.js app of course) and low-code. In theory, your own node.js app might be more efficient since you can optimise it but whether that makes a real-world difference for an IoT setup is debatable I think (I'd be very interested in finding out actually). Either way, I would recommend using something like NGINX or Caddy as a proxy anyway, you can let it deal with the TLS encryption and any authentication. It's cache will, most probably, make a material difference to performance.
You might even consider using a central NR initially to prototype the service. NR is excellent for that since it means you don't have to mess with loads of boilerplate just to get the hosting and scheduling working. You can then make a later decision as to whether to convert that to a pure code version.
If using MQTT for edge-to-centre comms, I would generally recommend running MQTT at the edge as well and then configuring the brokers as a bridge. That way, you don't have to worry about exposing the edge NR instances to the Internet and can focus on securing the MQTT bridge with TLS and id/password. Bridging also lets you control what topics are allowed to go in which direction.
