Der spannende Fehler ist hier: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed - wobei sich mir auch nicht erschließt, woher der kommt. Inhaltlich besagt er, dass sich der Server nicht ordentlich ausweisen kann.
Eine waffenscheinpflichtige Umgehung ist, diese Prüfung mit SSL_verify_mode => SSL_VERIFY_NONE abzuklemmen: Dann wird nur geprüft, ob das Zertifikat vom Format her korrekt ist. Sowas ist aber bestenfalls in einem separaten Netz sinnvoll, in dem mit selbstsignierten Zertifikaten gearbeitet wird.

Der Rest sind ja keine Fehler, das ist ein ganz normaler Debug-Output. Mit höheren Debug-Werten bekommst Du auch die ganzen verschickten Datenpakete.

Drei Fragen:

• Kannst Du denn mit dem Firefox eine FTP-Verbindung herstellen? Dann kannst Du prüfen, ob bei dem Zertifikat etwas verdächtig ist (Firefox ist, genau wie openSSL, recht kritisch)
  
• Kannst Du den Debug-Output mal für einen FTP-Server erzeugen, bei dem die Verbindung funktioniert? Dann siehst Du, wo genau die Abweichung in den Protokollen auftritt.
  
• Welche Version von IO::Socket::SSL ist das? Bei der aktuellen 2.068 habe ich andere Zeilennummern...

Noch ein paar Details:

• 234 AUTH TLS successful sagt nur, dass die Verschlüsselung eingerichtet werden soll - da ist sonst noch nicht viel passiert. Das TLS-Theater beginnt erst danach.
  
• did not get stapled OCSP response ist nicht weiter schlimm. Das ist nur eine Performance-Optimierung, der Default bei IO::Socket::SSL ist "probiers, wenn's nicht geht, dann eben ohne". Du kannst per Option SSL_ocsp_mode => SSL_OCSP_NO_STAPLE abklemmen, aber ich prognostiziere, dass das am Resultat nichts ändert.
  
• SSL_verify_mode => SSL_VERIFY_CLIENT_ONCE sollte in der Tat gar nichts bewirken. Das ist nur für die Serverseite relevant, und auch dann nur, wenn der Client (also zum Beispiel Dein Code) sich ebenfalls mit einem Zertifikat ausweist. Laut Dokumentation wird der Wert beim Client schlichtweg ignoriert.