It is only the NX 'server' and 'client' processes that uses a special user account named "nx". These accounts serve to setup the initial stage of the connection and use the keypair you mention, and this is all before the real user login happens. That key is NOT used for login of the real NX session user.
Once that initial stage is completed, there exists a secure, encrypted channel. It is then this encrypted channel (established with the help of the default NX SSH key) that is used to do the real user login.
Hence, with only knowing the default SSH key, nobody can login to an NX server. He can only start the initial 'handshake' phase and is then stucked.
That is just like if you login to a HTTPS server, which pops up the username+password dialog box... [And would you consider that to be particularly insecure: a password dialog box popping up before the HTTPS user login is completed?]
Of course, for a warm feeling of additional safety, you can create your own key and replace the default NX/NoMachine keys -- best if you create a separate keypair for each different NX server. Hmmm.... this user-known key(s) then you must distribute to all users of your respective NX servers. And you must now start to do more administrative work to manage all the keys for the different NX servers. Additional security comes with additional work....