I have had this issue, clients able to download 4 Mbps TCP, but upload is only 0.35 Mbps.
This was using 48Mbps Airrate on 2.4 ghz, 5Mhz channel sizes, with 3 x 120 degrees sectors operating at 2417, 2447, 2472 MHz.
This is most likely a CSMA back-off issue, your clients are directed at you tower (ie. pointed at all 4 sector antennas), the sectors while being 90 degrees do radiate more then 90 degrees, and if you client radio 'hears' any of the sectors transmit it will backoff.
The CSMA function is very very sensitive, in lab tests it doesn't matter if signals the client is 'hearing' is -85, or -50, it will still backoff.
The disable CSMA function should solve this issue but it doesn't work very well in RouterOS, the biggest issue in my opinion is that Nstreme needs to be on to use that function, and unfortunately Nstreme is very sensitive is noisy enviroments, and that is where the disable CSMA is most needed.
You can easily test this, wait till 3am or whenever your sectors are not in use much, do the same tests with 3 of the 4 sectors off (ie. radio disabled). Post your results becuase I am afraid that this issue is alot more serious then what many people realize. A simple 802.11b,g router with moderate usage in a house near any of your towers/cpe can have a significant impact on the performance of those devices.
I have had my fingers crossed for some time to get a Nstreme version that improves the connection in noisy enviroments instead of making it worse.
Edit: The screenshot you posted didn't load for me the 1st time, and I didn't see what you were referring to. If you are talking about the association TX/RX rate being 1 Mbps, that is because in Mikrotik it backs the radio rate down if it is not needed, this is normal operation. However if you want, and your clients have the neccessary signal strength, you can go to the 'Data Rates' setting for your wireless cards, and configure the rates you use. I use this extensively with my APs, having radios continously switch Data Rates decreases overall performance.
If however you were actually referring to actual upload bandwidth (raw TCP/UDP), then my original post is still correct.