I don't know much about R, so I can't delve into any R specifics here. That being said:
In general, in imperative, procedural and functional programming languages (and maybe in some other paradigms as well), calling a function will block until that function is finished, and pass out the function's result to the caller. This is typically is a good way to do things, however in some cases, we might have requirements that make this a less viable modus operandi.
For long running operations, we might not want to block the caller for so long. Depending on the environment we're in, the caller might not have the possibility to spawn another thread, or the possible number of threads might be too small to accomodate the required number of parallel calls, so doing long-running operations in this synchronuous way will give a very bad experience. JavaScript with its single-threaded model and frequent neccessity to make calls to a server is a typical example.
So the basic idea of Callbacks is, instead of having the called function return when the actual processing is complete, the caller passes in a Callback object (in OOP, in other paradigms something similar, e.g. a callback function, often anonymous, for functional programming). The called function will return immediately, freeing the calling thread to do other stuff. When the long-running process is finished, the Callback will be called and it is there that the caller can process the results given from the long-running process.
This schema can be generalized a bit, so not only will the callback called at the end of the processing, but also regularly while processing, providing some kind of status update, so the caller can e.g. display some feedback to the user (status bar, estimated time to completion, ...). Another common addition is a way for the caller to cancel the task while it is being processed.
That's the general principle. Maybe someone more knowledegable can fill in the details of how this applies to R and where R differs from this general description.
