Yes, it's possible for the root user on B to snoop your traffic, although you don't say exactly what OS it is. On Linux, that might include the
ttysnoop program or using a debugger against sshd.
I've used tunnel-in-a-tunnel a lot (as well as SSH over PPP over SSH, which is yet another layer), and it doesn't necessarily have a serious performance or latency burden. Of course, there is some overhead, but not more than the usual variability of a connection.
Consider the worst case for a single character. In Telnet that would be sent as an Ethernet frame with a payload of 46 bytes (20 bytes IP header, 20 bytes TCP header, 1 byte data, but the Ethernet standard requires 46 bytes minimum payload, 42 in a VLAN environment). In SSH it would be a payload of 68 bytes ("The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus 'mac').", RFC 4253); I see 92 bytes watching an actual connection with Wireshark. In SSH-over-SSH there's the overhead of SSH framing; I see a payload of 140 bytes.
Sending a lot of data, SSH uses frames (over TCP, hence not limited by packet-size) of up to 32k bytes, so the overhead of double-tunneling is negligible. It takes me 20s to transfer a 2M file to a VM that I can access either through an SSH tunnel or via SSH directly. If I
dd a 36k text file, it takes about 84 packets almost all 1380 bytes long to send from a "simple" ssh session.
Lastly, the exact command you gave,
ssh user@B ssh user@C
probably won't do what you expect; this second "ssh" will probably give the message "Pseudo-terminal will not be allocated because stdin is not a terminal", and you'll get a shell that does not prompt you for input or support command-line editing. Instead try
ssh user@B -t ssh user@C
Also note that this could actually result in more small packets (= TCP header overhead and real delay) if the B host can't keep up with the data coming into it.