I see. I completely agree that the history size should be at least 144 x the sample size, but what i meant is that since you're getting 10x as much data for each request when using the API v2, you probably don't need to fetch as many times as the original bot did when using the API v0. In that regard, obtaining 144 samples' worth of data does not necessarily mean having to make 144 requests to the API.
In my experience, the MtGox API is more defensive against the time between each request (hammering will get you banned for a while) than to the actual number of requests itself. In the case of the bot, i think the time it takes to parse the json and fetch the next request should be enough timeout. You could always add a small timeout in between requests if i'm wrong, but since it seems to work as-it-is now, i think you should be okay with an even smaller number of requests for the same amount of data.
But the problem with fetching historical trade data at given points in time with MtGox API is that the bot only wants ONE trade (the first one) from each chunk of trades. The rest of the data is usually not relevant since we need samples at the correct points in time (if the sample interval is very short, there COULD be more than one useful trade in the chunk, but in most cases there are probably more than 1000 trades between each sample time, so only the first trade is useful. So in most cases we have to make one call for each sample). If there was a way to specify how many trades to fetch with each call, I would set it to 1, but as far as I know that's not possible with any API version...
But caching data should cure some of the problem. Then you could at least restart the bot/browser without a new storm of calls to MtGox. But as you said, it's probably ok - while developing, I need to restart the bot all the time, causing 144 calls to be made, and I don't think I've been blocked...