The documentation of Postfix is very specific in that the problem occurs if a client offers ciphers which the client does not implement properly. To cite from the documentation:
... some SSL clients have listed lower priority ciphers that they did not implement correctly. If the server chooses a cipher that the client prefers less, it may select a cipher whose client implementation is flawed.
In other words: problems occur with this setting if the client a) has broken ciphers in the first place and b) offers these ciphers even though they are broken and c) relies on the server not to pick the broken ciphers the client offers.
"Windows 2003 Microsoft Exchange clients" where only provided as a known example of such broken implementation which does not mean that their are no other broken implementations. Contrary to HTTPS (where it is not uncommon that servers prefer there own cipher order) there is a large variety in mail clients (including MTA trying to forward mail to the next hop) and the chance to communicate with some broken implementation is therefore usually higher. This does not mean though that setting
tls_preempt_cipher_list=no will work around these problems in all cases. But it might increase the chance a bit that client and server will actually agree on a cipher which is properly implemented in the client.
Apart from that it should actually not really matter if the server picks the cipher based on the clients or the servers preference. What matters though is that the server has only ciphers configured which are considered secure. In this case it does not matter if the client offers insecure ciphers since the server will not pick these as common ciphers, no matter if the cipher preference is taken from client or server.