My PHP skript runs "fail2ban-client status haproxy" to get a list of blocked ip-adresses to process it further.

Would probably not solve the issue, but fail2ban-client get <JAIL> banned is probably more appropriate command to get a list of banned IPs.

Maybe it is not possible to run fail2ban-client two times?

Nope. At least not in direct sense, for instance in my IDS based on fail2ban I definitely had nested calls of fail2ban-client in some actions, but... they was affecting different jails.
However it is only based on fail2ban, so some things may deviate, especially parts affecting asynchronous handling in server.

The actual problem is that fail2ban-client works here synchronously, so it waits for an answer from fail2ban-server, which in turn calling actions.removeBannedIP also totally synchronously:

If the action during unban, triggered by server, calls fail2ban-client again, it'd expect that server thread listening on the socket and process the command too, what would not happend because server thread is going to process actions.removeBannedIP in that moment.

Because of #3487, we need to rewrite the server communication anyway, so it'd be theoretically solved after switch to asyncio facilities, but...

Additionally (second problem that may occur) if inside the action something calls fail2ban-client status haproxy which needs also an access to actions object (its banmanager) to get the list of IPs and this may get blocked by some common lock (I don't think it is GIL, rather some lock protecting lists/queues).
In this case it'd be also a deadlock, since the thread of server blocking a mutex for that in turn the actions thread waiting.

The full solution may be to rewrite calling of actions.removeBannedIP asynchronously or to send from server thread an event to actions thread, instead of direct invocation of actions.removeBannedIP there.