So I did some digging into this and looking at the differences I mentioned.
It appears that there is a distinct difference between how the Jenkins -> Node -> <agentName> UI page shows to launch the agent and how the ECS Plugin and Docker image entrypoint are launching the agent.
The Jenkins UI shows you to basically call it via:
java -jar /usr/share/jenkins/slave.jar -jnlpUrl <jenkinsUrl>/computer/<agentName>/slave-agent.jnlp -secret <agentSecret>
Which as I've deduced is calling using the hudson.remoting.launcher class using the jnlpUrl to pull down the encrypted JNLP file which it then decrypts using the secret and executes the hudson.remoting.jnlp.Main class with the arguments specified in the JNLP file.
Whereas the ECS plugin and the typical Docker image entrypoint script launches the agent using a call like:
java -Dorg.jenkinsci.remoting.engine.JnlpProtocol3.disabled=true -cp /usr/share/jenkins/slave.jar hudson.remoting.jnlp.Main -headless -url <jenkinsUrl> -tunnel <tunnel> <agentSecret> <agentName>
Which directly calls the hudson.remoting.jnlp.Main class and passes the arguments directly requiring it to have intrinsic knowledge of the arguments needed.
The hudson.remoting.launcher already appears that it executes with -headless already enabled and seems that calling the JNLP URL would be much more future proof.
Obviously if the array built by the com.cloudbees.jenkins.plugins.amazonecs.ECSCloud.getDockerRunCommand() is changed this would require a change to how the entrypoint script handles it. So does it make more sense to do so?