Armory spoofs itself as a node to your Core instance in order to get new mempool entries, new block notifications and push transactions. There is no ACK in the Bitcoin p2p protocol for transaction broadcast, you can only query Core's mempool for your transaction's hash to figure whether it made it in.
This is the timeout mechanic, Armory isn't gonna hang forever for the transactions to make it in. It doesn't mean Core didn't accept the tx. Core tends to batch transactions together before processing them and pushing them to other nodes.
Eventually, I added a fallback to use the RPC, which with you an actual ACK. You have to consider that at the time this stuff was designed, the RPC was much harder to setup, so RPC broadcast never was considered a default. You still get the error message because ArmoryQt brokers the RPC connection so it hsa to be made aware of p2p broadcast fails in other to attempt a RPC push.
1. Why did the transaction not go through the first time, but did the second time?
Possibly an actual timeout where Armory didn't deliver the tx to Core before the timeout expires. Armory has to announce it has tx by hash and Core has to ask for its body. This part of the exchange can timeout as well (Armory just waits 10 seconds before calling out a timeout, it doesn't care which part of the process it failed at). Usually timeouts occur at the second half: Core took the tx and Armory is polling its mempool to see if it made it in.
What is the meaning of the error and how can I avoid it?
You can't avoid this error in the current Armory. Even if you have RPC up, you will be notified of a p2p broadcast timeout if that actually happens. If your RPC is set, the fallback should see you through regardless.
The new broadcast code in the upcoming release deals with this stuff directly on the DB side (ArmoryQt doesn't talk to Core anymore, it's all handle by ArmoryDB). It also has a better way of handling Core mempool poling so the timeouts are less likely to occur.
Is there anything else to keep in mind in this context? For example, are there any risks in accidentally broadcasting a "_SENT" multiple times?
You can't rebroadcast a tx that is already in your node's mempool or the blockchain itself. Current version has poor verbose around this. Next version gives you a fuller error report in this kind of cases.