It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders.
Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
Both sides have to generate secure random numbers in order to perform an ephemeral diffie-helmann exchange securely; if the client's random number is insecure, a man in the middle attack becomes possible.
Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.
But surely the client could use human input as it's source of randomness too : After all, in this case (browser purchases) the user is going to be hitting keys and/or moving the mouse.
Using a physical process is generally going to be harder to exploit than a software one. There's going to be the possibility of uneven distribution (customer order timestamps may cluster at certain parts of the day, rather than being evenly distributed), as well as the (granted, small) possibility that on some small site without Amazon scale, the attacker can generate enough entries that it can reasonably assume one of them will be picked by the random index.
Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.