The most common reason is because I have a large problem to work on and it naturally just gets input from some non-interactive source, crunches on it, and stores the data back somewhere. But sometimes, I'm building an interactive application and want to decompose it into an interactive portion and a batch portion.
For example, a web app might need to do a time-consuming set of computations. It may make the application easier to write if the UI front end submits a job to the batch portion of the system, waits for the result to appear and then generates a response page to the user. There are some security advantages to this--if you get hit with 1000 requests to do the expensive operation the batch processing system is a natural place to start throttle them down. Also, the batch processing computers can talk to databases while the web servers that are exposed to the internet can be prevented from directly connecting to databases.
One thing I've learned is to try and make the batch processing application always make small incremental progress. The ideal is that for every N seconds the batch processing system runs, that it should get k * N percent closer to being done. This way if your system runs for 24 hours and then crashes you still have something to show for it. Breaking your tasks down into small pieces of work that can be completed and re-started without having to start from the beginning is very helpful.
For example, suppose our batch application takes as input a list of images to download, virus scan, resize and then store into a db. Depending on the size of the images and how long it takes to download them, you might consider having one thread/process downloading images, another virus scanning downloaded images and a final thread resizing them. If the downloader thread crashes, it can restart where it left off and the other threads wouldn't be affected unless they ran out of images to process.
