I don't actually know the answer, but I think I may understand what they are on about.
My thoughts:
the backhaul back to their core network from the mini-DSLAM in the street via the exchange is all symmetric (i.e. same maximum speed up and down). However the VDSL service on customer lines is asymmetric.
The profiling is used to prevent an overwhelming amount of traffic hitting a given route.
e.g. you choose to download a massive file from a server on the internet somewhere that can happily serve that file at say 300Mbps+. All well and good - 300Mbps flies across the internet, over BT's core, down the backhaul to the DSLAM in your cabinet - at which point it hits a bottleneck as your downstream rate is a lot lower. The net result being buffering and/or discard of data by the DSLAM, in turn resulting in the dropped packets needing to be retransmitted again all the way from the server somewhere on the internet.
Not a very sensible thing to do as that would throw a stack of useless traffic over the backhaul to the cabinet which could unnecessarily lead to congestion as well as incurring the additional back scatter of upstream retransmit requests coming from you.
So the downstream data rate is limited so as not to bottleneck when it hits the VDSL segment. I presume this is applied at the BRAS so it relieves the unnecessary data from their on out i.e. the fibre feeding the exchanges and the fibre to the cabs.
Now think about the upstream - as far as BT are concerned - what need do they have to profile the data rate on that? You can only generate as much traffic as the VDSL segment can handle in the upstream direction which poses no risk to the onward upstream fibre capacity into the core.
To BRAS profile on the upstream would be plain stupid as by the time the data arrives there to be throttled it has already traversed the "narrowest" part of the network i.e. the fibre from cabinet to exchange. Upstream needs to be managed on the CPE (your router) which would be achieved by capping the VDSL synch rate in that direction or using capping on the VLAN (presuming the CPE is intelligent enough).
Basically what I believe they are saying is that they have no concerns about upstream congestion becoming an issue so they don't bother profiling it. Understandable really as downstream congestion is going to occur sooner on the symmetric backhaul, which will require the backhaul to be increased in size - adding more available upstream... and so on.
And yes - before anyone jumps in - I'm deliberately ignoring the ability (or otherwise depending on implementation) for the TCP stack to back off the transmit speed in either direction if required. It's a somewhat unreliable mechanism over the t'interweb.