Alright: you cannot have an answer here which does not even mention the word "IP" once. I need to fix that... The important stuff is in the first section, you can skip the Motivation sections if you are short on time.
The onion (OSI model)
Let me make this very clear: When talking about networking, it is fundamental that you start thinking in layers. In the case of the internet, this means the OSI model:
- Layer 5, 6, 7: session, presentation, application (in short: application stuff).
- Layer 4: Transport; Segment (TCP) / Datagram (UDP); Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing.
- Layer 3: Network; Packet (here: "Internet Packet" or "IP"); Structuring and managing a multi-node network, including addressing, routing and traffic control.
- Layer 2: Traffic between two nodes (here we have MAC addresses and such, that is, Ethernet).
- Layer 1: Physical bits and pieces (cables, electric protocols, but also WLAN radio waves and low level encryption).
(3 and 4 copied from Wikipedia, the rest shortened as it is not relevant here.)
While, in theory, you could use any layer in routing decisions, the OSI model (at least up to and including level 4, above which things become a bit foggy) is not some theoretical CS construct, but absolutely practical and "real". The term "routing" is firmly attached to layer 3, and it does happen, for all intents and purposes, and exceptions nonwithstanding, on layer 3. That means: IP packets are routed. We neither route Ethernet frames nor TCP or UDP connections.
TCP/IP is routed the same as UDP/IP because neither TCP nor UDP plays any role. Usually; it is only the "/IP" part that is relevant here. If there is any distinction, it is whether the protocol is TCP or UDP as such (for example: if you are playing an online game and it uses UDP, you might decide to send all your UDP to some separate low latency link instead of your high latency bulk link), not whether an individual IP belongs to an individual TCP or UDP stream.
Another example would be a TCP/IP connection like a shell session. Let's say you open it at morning and keep it open until the night (and assume there is no timeout/auto-logout feature...). Then it would be totally useless if you were somehow forced to use the same route all those hours; it would be much more useful to be able to decide for each packet, say if an intermittent failure knocks out a certain path for a while.
Also, high bandwidth routers have their hands full with loads (sic) of things, even if they look only at IP and not higher layers. Big routers are already very expensive, and it is really not an easy job they are doing.
Now, if you would want to keep track of TCP connections, you would introduce an additional kind of stream-based state to the routing decisions. While there may or may not be routing algorithms out there that do so, you can imagine that for the usual case, it would serve no purpose whatsoever to take on this additional CPU and RAM burden on some anonymous router somewhere in the wild of the 'net. There might be some useful applications if your application is closely coupled to the actual router sitting in front of you, but that would be an extremely special case.
That is why we have packet based switching/routing in the first place, amongst others: we fully accept, nay, demand, that there needs and usually can be no fixed path between source and destination. In the past, static routed algorithms needed to keep track of the route for each connection; this is not so anymore.
So even if there may be some exception to the rule and even if you do find some advanced router that has some way to influence IP routing based on their TCP or UDP payload, for the vast majority of existing routers/networks you will not find such. And if you do, those TCP based features are more likely to be used as intrusion detection (i.e., more like a firewall) or closer to a proxy than for pure routing purposes. And even then, you will likely find that they are doing their connection inspection stuff while not caring about routing at all.