One is that it's impolite to everyone else who uses the site, you're draining resources away that people who want interactive exploration of the block chain need, for a very simple functionality.
Well, they
do provide an API that lets you do exactly what OP wants. I don't see how it can be considered impolite to use that API, especially if you only poll it once every few minutes. Your other reason is very valid though.
The API info states that by default the limit is 300 calls/5 min. or 5760 / 8 hours, and that you can contact them to have the limit increased. I don't see how a call every 3-5 minutes is going to be impolite or a problem given the stated limits. It's very clear from the API docs that using it this way is one of it's intended purposes.
It's not just that I don't want to have bitcoind running on the server and the space it uses but also that AFAIK it doesn't provide a useful interface for monitoring a large collection of randomly generated addresses. There are some calls to check various wallet values but I don't think there is a way to setup callbacks upon payment arrival. So I would end up repeatedly polling by RPC for potentially thousands of addresses that only a few may have a payment arrive on. And then it doesn't seem to provide a way to add addreses without keys. So unless there is a better suited daemon I can run then making use of the JSON API looks like the best way.
After trying some stuff and coding for a while I decided that likely the best way was to poll the simplest "getblockcount" call to see when a new block arrives. This call only returns a number and is very lightweight. When a new block arrives I don't grab it. Instead I grab the one that is N block before it and check those transaction addresses. They already have the needed confirmation level and so can be applied to balances in one step. Much simpler.
One thing that would make such use much lighter on the API server would be to offer a much reduced block-height call. For payment processing it seems you only really need the (trx,address,value) output tuples and that is a small fraction of the overall block data. Blocks that currently are 500K in size would likely be 5-10K if useless data was pared away.
