At some point in the dim and distant past a radio designer who knows nothing about CW contesting decided that PTT via RTS over RS232 or a serial emulator cable was unnecessary. This decision was then used for all future radios, worst still other manufacturers then started to copy this mistake and soon a major problem was born.
There are so many usage factors for a ham radio that the manufacturers today have trouble knowing which groups to listen to i.e. casual ops, data ops, dx ops and contest ops.
Casual ops: If the radio kind of functions...what's there to moan about? Its fine.
Data ops: As long as FT8 mode works, and the rx/tx switching times are good, I'm fine.
DX ops: The rx performance needs to be good, I need all modes, as long as I can hear, I'm fine.
Contest ops: The rx performance needs to be good, the tx performance needs to be good, rx/tx switching times needs to be good, I need all modes, the ergonomics need to be good, interfacing needs to be spot on, filtering needs to be good etc etc etc.
In short if you want everyone to be happy, ask a contester as they are striving for the best.
However, serious contest ops are few and far between and there are all sorts of grades of contest ops out there from casual little pistol through to those who own super stations (big guns). Casual contest ops are not that interested in efficiency as they are not really competing, just having fun.
Anyway back to the point in hand PTT via RTS over RS232. Contest ops send macro cw exchange messages from contest logging software to the radio and also 'fill in' messages via the key. TX -> RX time is critical i.e. the release of PTT. The reason for this is that good contest ops are efficient and speed is of the essence, so very little time is wasted in a fast exchange between 2 stations, so much so, a casual listener may not be able to hear a perceivable break between the 2 stations. Serious contest ops use a computer to transmit their side of an exchange (now, now... if you don't agree, I am sorry you are not a serious contest op), this means the computer 'knows' exactly when the exchange message will end ahead of time. No other piece of equipment can know this information before the computer, so it can unkey immediately after sending the message. It therefore stands that the most efficient exchange can only be accomplished by the computer using RTS to signal PTT.
Now enter the radio manufacturer. They are ignorant to the above fact and decide that they will only provide PTT sourced from the radio. The PTT mode relied on here is called break-in which detects cw keying over DTR from the computer and then uses a controllable delay time after the last cw keying action to release the PTT automatically. Unfortunately this causes a delay after every part of the sent exchange where the radio remains in tx for the delay time despite no cw being sent over DTR. The result of this is a really inefficient exchange and many, many unhappy contesters.
It may seem like an little thing, but serious contesters are striving for the best and this kind of PTT implementation is unacceptable, especially when Elecraft, Icom and Kenwood seem capable of getting it right.
It doesn't seem like much to ask for from a £3000 radio and the inclusion of this basic expected functionality hurts no one else's usage case. Hopefully ham radio manufacturers want to be the best?