I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.
Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
At some point, a website or person accepting a transaction
must take this risk. It is unavoidable, whether you use listreceivedbyaddress or listtransactions. This is why listtransactions reluctance seems so unusual.
Almost every exchange or website accepting bitcoins achieves a
binary decisionpoint, where the transaction is accepted, and goods are shipped or money is exchanged. After that binary decisionpoint, even if the block chain is reorg'd or transactions disappear, there is nothing the website can do but take a loss (or pursue a refund outside of bitcoin).
From the website's point of view, there is zero effective difference between 'listtransactions 6' and 'listreceivedbyaddress 6', because the end result to the website operator is the same: the goods have been shipped / order accepted / money exchanged.