The onjcmd mechanism was introduced through JDK-8214892 "Delayed starting of debugging via jcmd". It brought the possibility to start the JVM with debugging capabilities but without an open port to attach and with less performance penalty compared to starting the VM with fully armed debugging. So it offered a from of "On demand debugging".

However, the option was far from complete in the sense of a real "On demand debugging" such as envisioned by JDK-4841257. For debugging there is a requirement of certain JVMTI capabilities that currently need to be registered at JVM startup and can not be enabled on the fly. For a real "On demand debugging", the implementation would have to be changed to make these capabilites dynamic.

The performance penalty between starting with debugging agent enabled for use with onjcmd vs a fully loaded debugging agent was addressed in the meanwhile through JDK-8227269.

Also, the onjcmd implementation is lacking functionality to manage the debugging port, e.g. closing it or assigning it a different port number through jcmd etc.

As it stands, there's not much benefit left from the onjcmd facility and we should remove it to reduce technical debt. Maybe some of it will return if "On demand debugging" is ever addressed but then more thought needs to be spent into the whole thing.