The following has been noticed on 3 machines running:
RHL6.2 kernel-2.2.19-6.2.12 (errata) xinetd-2.3.3-1.rh6.2
(my own build, using xinetd-2.3.3-1.src.rpm as base, only with minor 
modifications in prereq in order to make it install)
RHL7.1 kernel 2.4.17 (custom build) xinetd-2.3.3-1 (errata)
RHL7.2 kernel-2.4.9-21 (errata) xinetd-2.3.3-1

On all three, I run (at least) these two xinetd services:
proftpd 1.2.5rc1
a redirect service that forwards from a port on eth0 to another on localhost

Both services have "bind = <ip address of eth0>"
Proftpd obeys the global "cps = 5 10" directive.
The redirect service has a "cps = 5 5" setting of its' own.
The redirect service is required in order to provide tcp wrapper ACLs for the 
target daemon (listening on localhost) that doesn't provide such facilities.
Proftpd runs with "user = root".
The redirect service runs as a non-privileged user.

What I noticed is this:
The proftpd service gets disabled due to excessive incoming connections. After 
10 seconds, xinetd tries to reenable it, but it logs

Feb 19 12:29:42 frixos xinetd[581]: Deactivating service proftpd due to 
excessive incoming connections.  Restarting in 10 seconds.
Feb 19 12:29:47 frixos xinetd[581]: bind failed (Address already in use (errno 
= 98)). service = proftpd
Feb 19 12:29:47 frixos xinetd[581]: Error activating service proftpd

From that point on, the connection to the proftpd service port (21) is not 
refused; the socket is opened, but the server doesn't seem to be running, 
because no login prompt or anything else ever comes up.

Next, I tried to manually reload xinetd configuration a little later, hoping 
this bind failure was only a temporary problem caused by xinetd's children not 
having closed some sockets yet in these 10 seconds.
Unfortunately, I get the same "bind failed" error as above with the same 
results.

The only way to solve this is to restart xinetd, effectively killing all 
running instances of both the redirect and proftpd (any any other) services.

It was easy for me to reproduce this problem: since tcp wrappers are used, I 
only have to trigger a flood of connections from an IP address not allowed to 
connect to the proftpd service. So this will do:

# i=1 ; while [ $i -le 15 ] ; do telnet -b <notallowedip> <targethost> 21 ; 
((i++)) ; done

(connection is closed after it is denied by libwrap, so a new telnet starts 
almost immediately, resulting in excessive incoming connections)

I reproduced this situation (after restarting xinetd). This time, when the 
service couldn't be reenabled, I noticed this:

# netstat -lpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name
...
tcp        0      0 frixos.csl.lab.me:ftp *:*                     LISTEN      
17024/xinetd        
...

# ps ww -p 17024 -o pid,user,command
  PID USER     COMMAND
17024 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid

This is a child of xinetd, and it should be listening on the redirect port, 
not the ftp port.

# fuser -v -u -n tcp 21

                     USER        PID ACCESS COMMAND
21/tcp               root      17024 f....  xinetd
                     root      17025 f....  xinetd
                     root      17028 f....  xinetd
                     root      17030 f....  xinetd

# ps ww -p 17024,17025,17028,17030 -o pid,user,command
  PID USER     COMMAND
17024 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17025 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17028 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
17030 nobody   xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid

These processes should belong to the redirect service. I don't know why they 
are reported to use this port; fuser says they run as root, ps says they run 
as nobody.

Then I thought maybe this bind failure error happens because both services use 
the 'bind' directive. I removed it and reproduced the situation that caused 
the problem, with the same results though.

Finally, I disabled the redirect service, restarted xinetd, and tried again. 
This time there was no problem: xinetd reenabled the proftpd service after 10 
seconds without errors. However, even after I enabled the redirect service, I 
noticed the problem would still not happen, as long as no redirect service was 
running.
After that I also tested with other service combinations, apart from proftpd. 
AFAIK, any xinetd service with socket_type = stream, protocol = tcp, wait = 
no, together with a tcp redirect service will produce results.

So I am almost certain this is a xinetd issue.
After all this tiresome reading, the question is: is anyone aware of this 
problem? I don't know if it has been fixed in rawhide, but I can't afford the 
multiple xinetd restarts it will take in order to test it, at least not before 
asking you guys first :)