No, your conclusions are not quite accurate. Flow and congestion control have different goals.
the goal of flow control is to ensure that the sender is not overloading the receiver
the goal of congestion control is to ensure that the sender is not overloading the network, e.g., by sending much more packets that the link with lowest capacity on the path can process and transmit.
So, short answer holds, but it is not exactly about limiting the capacity.
First, if the receiver is connected by a 10Mb link, than the system that will be overloaded is not the receiver, but the "kinda other side of that link" (basically if there is a router that has 100Mb incoming and 10Mb outgoing link, than it will be the overloaded system in this scenario), which is then the problem of congestion control.
The receiver is supposed to have a buffer, where it stores received packets. This buffer is needed for TCP operation when the packets are reordered. On desktop PCs this buffer is also needed to store packets when the application is not reading packets from the socket. This buffer can store a range of continuous sequence numbers. If a packet with a sequence numbers outside this range is received, the packet is discarded.
Now, the goal of flow control is not to send packets that will be discarded. The receiver tells the sender how much space there is in a buffer and the sender is not sending more packets that that.
The issue here is that you can't usually say that the receiver can process 10Mbps. It depends on how many reordered packets arrive, and on how process scheduling is done on the receiver. So this varies constantly (unless you have a real-time OS, in which case you would probably not use TCP to begin with).
The goal of congestion control is to adjust sending rate to the capacity of the network in between, which is more or less the capacity of the "slowest" link on the path.
Here is a classical example.
sender <=== 1Gbps ===> router (R1) <--- 50Mbps --> router (R2) <=== 1Gbps ===> receiver
So, the sender is connected to a 1Gb Ethernet link and is capable of sending 1Gb worth of traffic. Receiver is also connected to 1Gb link and its buffer is set accordingly. So TCP can technically send 1Gbps worth of traffic.
Obviously there is no point in sending 1Gbps worth of traffic, because the bottleneck link between two routers will not be able to transfer it. The extra packets will just be dropped at R1.
The goal of congestion control is to figure out what the capacity of this bottleneck link is and to not send more packets than this link can transmit.
Why packet drops? So, packet drops will occur at R1 because it tries to send traffic from 1Gb to 50Mb link. The way packet-switched network is supposed to work: R1 receives packets from 1Gb link; R1 need to send packets out of 5Mb link. R1 should have a buffer before the link. Ether the link is free and packets can be sent, or they should be buffered. Once the buffer is full the packets are dropped. This drop is taken as an indication of congestion. When packet drop occurs the idea is that the sender should reduce its sending rate.
Well, since TCP is window based and congestion control is window based, what actually happens is that TCP reduce the number of packets it sends out per RTT.
Now, I will leave the discussion on how good congestion control works, since it requires a really long wall of text. Tahoe is too aggressive, and degrades performance. Normal sender uses at least Reno.