The OP expects somehow for the server to prevent the client from = exposing information when the server has no control over what the client = sends. This simply is not possible and hence should not be expected.
Even if the server were configured only with a ldaps:// listener, = clients would not be precluded from sending a password to the server in = the clear. A client could be told to connect to that listener and send = a LDAP Simple Bind with password without ever attempting to start TLS. = Sure, the server will error, but the password is exposed none the less.
As you indicate, the same issue exist in more robust clients as well. = It's quite hard to provide client configurability and prevention from = misconfiguration which lead to security issues concurrently. How is the = client software to know that StartTLS or ldaps:// was wanted with it = wasn't so configured? The best a robust client could do here is warn = the user of security concerns that arise from their configuration = choices.
I would have no objection to adding such robustness to OpenLDAP command = line tools so long as such warnings were off by default. Kicking out = warnings as the default would likely break a lot of scripts which use = OpenLDAP command line tools.
-- Kurt=