Again the key advantage here is the "only_from" bit, which you can set to only allow swat useage from your own machine. (Of course this could have just as well been firewalled off providing a single point of filteration of rather than having it in the firewall, and or xinetd and or the application itself.
So there is a slightly finer grained control available in xinetd but there are other ways to achieve this control (firewalling with iptables etc) and you can't afford to be without those, so you get a lot of redundent settins that have to be maintained in two places.
Redundancy isn't a bad thing, consider it to be "complementary." Personally, I appreciate the ability to reinforce my security policies at multiple layers and on multiple devices. A filtering rule which is enforced by the application and IPTables on the box (and the firewall and even the router) means that I need to make configuration modifications in a number of locations, increasing the maintenance load as you say. The advantage however is peace of mind. I know that no single point of failure is going to leave me open. If my IPTables script is misconfigured, I have reliability of policy enforcement by the daemon. Likewise, if my firewall (God forbid) is compromised, my policies are still enforced on the box. Too many administrators believe that a firewall is the be all and end all of network security. It isn't. xinetd replaced inetd in most environments several years ago because of this fine grained control. Anyone that knew what they were doing back then was wrapping inetd; xinetd is an elegant replacement for xinetd/tcpwrappers and (in my view) should be considered a worthwile enforcement point for your security policies. -S.