It has to do something with threadpool, at least historically.
It is about providing an alternative scheduler to the threadpool, in unlikely case it becomes blocked (which probably only happens when threadpool_max_threads was configured too low).

It happens to work without threadpool, but what would it be good for, then?

This feature is very useful when an instance hits "too many connections" and you need to have some monitoring system still be able to report the status of the instance.
By default only one extra administrative connection is allowed but that could not be enough, and sometimes I've seen not even root being able to connect when "Too many connections" happened.
If you have the chance to have 5-10 extra connections for administrative purposes you can better monitor and manage the instance.
One recent problem I've seen is MaxScale not being able to monitor the instance because of this.
MaxScale could be configured so the monitor connects to that extra port so to never be cut out. The feature for this has been requested(https://jira.mariadb.org/browse/MXS-2167)
Only admin tools should know and connect to that port, if needed a firewall can be setup to disallow connections from the users or apps.

Well, claudio.nanni, I like your inventive interpretation. I'm just telling was it was for, originally.
You expand "one administrative connection" to N administrative connections, but in fact, you could just request his feature without extra port

I agree with wlad. The pages on which we document system variables should follow the context in which they were added or are maintained. These two are part of Thread Pool, so they should stay on that page.

That said, I think claudio.nanni's example is valuable. So, I rewrote the Troubleshooting Blocking Situations section to specifically call out using the variables to safeguard MaxScale monitoring. Do you think we should add this concept to the general MaxScale setup or to the specific MaxScale setup for enterprise/platform?

https://mariadb.com/kb/en/library/thread-pool-in-mariadb/#troubleshooting-blocking-situations

https://mariadb.com/kb/en/library/thread-pool-in-mariadb/#configuring-the-extra-port

https://mariadb.com/kb/en/library/thread-pool-in-mariadb/#fixing-a-blocked-thread-pool

Kenneth: Please review Geoff's edits

I was always under the impression that having the extra_port was only possible with pool-of-threads and not with one-thread-per-connection

Only today I learned that this actually works just fine with one-thread-per-connection, too, and so is a more reliable way to deal with "max_connections exceeded" than the classic "one connection reserved for SUPER".

Or at least on the 10.8 instance I tested on it worked fine, has this actually always been the case, or was this only added in later releases?

Tested with 10.0 now, and found it working just fine there, too.

So all these years I could have recommended this to customers who ran into "Too many connections" problems when exceeding max_connections due to high load, locking, or disk full situations and for whom the "one connection reserved for SUPER" did not work out, but never did as I was under the impression that it was a pool-of-threads-only thing.