For
very demanding applications, SFML's use of
select() (as opposed to
poll(); which AFAIK is slightly more scalable on some BSD's (but not as well as
kqueue()) and
epoll() which scales significantly better on Linux (and doesn't have the FD_SETSIZE problem) - on Windows I guess the prefered option is
WaitForMultipleObjectsEx()) may be considered a disadvantage.
But, as I said, this is mostly only relevant to
very picky applications and I doubt your game is one
The biggest "disadvantage" of TCP is (IMHO) also its biggest advantage: a reliable, in-order, stream. Being reliable and in-order simplifies life hugely for users of the protocol, but it does mean that whenever a packet gets lost (and they do get lost once in a while) or arrives out-of-order, then you pay a latency penalty while TCP times out and then re-transmits the missing packet or re-orders incomming packets (which may mean it has to wait for some of them). UDP does not have those downsides since it's not reliable, but then it has the downside of being unreliable so you have to implement your own re-transmit logic etc on top of it if you need that.
As for reliable UDP; as lxrec already said, SFML does not provide this - maybe you want to look at
ENet or a similar library for that.
Edit: also be aware of the impact that network buffer sizes can have on performance - be aware of the
bufferbloat problem.