I disagree that “if you don’t have a hidden node problem then changing the RTS threshold won’t improve performance.” Using CTR/RTS always lowers the chances of data collisions. Since every data collision causes data corruption and thus requires data to be re-sent, less collisions means less re-sending of data and less re-sending of data can largely improve your WiFi performance; of course only if there is a notable amount of collisions in your network.
To explain the details: A node always has to wait for a certain period of time and sense the channel for possible transmissions prior to stating an own one. Only if it doesn’t sense any transmissions, it may start an own one. Without RTS/CTS, this transmission is directly a data transmission. If now two nodes both have the same idea and start a data transmission almost at the same time, then these transmissions will collide. The result is, that neither transmission makes it anywhere as all received data will be corrupted for all other node and the AP.
If RTS/CTS is used, the transmission starts with a RTS packet being sent by the node after the sensing. Only if that RTS request is answered by a CTS reply, a data transmission is started. Of course, if two nodes want to transmit at the same time, their RTS requests can also collide with the same negative effect that no RTS is received at all. The difference is, the entire network will recover much faster from a RTS collision than it will from a data collision. So a RTS collision is less harmful to the entire network performance than a data collision.
The downside is that RTS/CTS itself requires some network bandwidth on its own and it introduces new sensing times during that no other data transmissions or RTS/CTS transmissions may take place. To make things even worse, of course RTS/CTS always has to be performed using the slowest speed the network supports as otherwise nodes only supporting this speed won’t see it. So basically you can say that RTS/CTS always lowers the theoretical throughput of your entire network, however if your network suffers by lots of collisions, either by the hidden node problem (which can also be caused by nodes from other networks just using the same channel as your network) or because your WiFi is crowded (as more nodes increase the chance for random collisions), it may in fact increase the actual throughput. Not the number of hidden nodes, the number of collisions is the important factor here, no matter how they are caused.
I read a study (I will update and add a link here once I was able to find it again), that suggests that unless your network is really small (less than maybe 6 nodes and covering only a small area) and not isolated from other networks using the same channel, using RTS/CTS almost always has a rather positive effect in practice. So why the threshold value? If sending the data would take as much time as a RTS/CTS handshake would take, there is little gain on using RTS/CTS, since whether the network has to recovery from a very small data collision or from a RTS collision won’t make much difference. The better recovery from from RTS collisions is because RTS packets are very small whereas data packets are usually not. But for very small data packets, RTS/CTS just adds overhead for no practical gain.
And now you also know how a fragmentation threshold can improve network performance. On the one hand it limits the size of packets sent and as explained above, the smaller the packet in a collision, the faster the network will recover from it. And on the other hand, if there was a collision, only the fragment affected by it needs to be re-sent, not the entire packet. However, every fragment sent has an overhead of its own, so the more fragments being sent, the more overhead that will add and overhead is basically wasted bandwidth that could as well have been used for data transmissions instead.