Since your example uses a JavaScript-like language (duck-typed), my answer will be specific to duck-typed languages.
From a usability standpoint, parameters are a tad more self-documenting then return values. If someone was crawling through code and saw:
function callback( model, rootElement )
{
//TODO: implement editor UI
}
It's a bit more obvious what should be done then:
function callback( model )
{
//TODO: implement editor UI
// ... okay, where?
}
In addition, curious programmers have a bit more to work with if given parameters. For example, imagine an Options object with 20 configurable options. Providing that Options object as a parameter (pre-loaded with defaults) gives the programmer a chance to poke into the object and explore a bit:
function callback( options )
{
console.log( options );
}
While a callback that must return an options object requires the programmer to find your documentation:
function callback()
{
// umm... return what?
}
In addition, if you want a value returned but the user doesn't return a value, what happens? I've seen many cases where this condition has produced "cannot read property of undefined" errors... which usually breaks the page.
If the user is handed a parameter and given permission to modify it, then you aren't depending on them doing anything. For example, perhaps the user just wants to log that something has happened and your callback is a convenient place to do that. Requiring that they return something just makes the code more complicated.
function setOptionsCallback( options )
{
console.log( 'object created' );
}
Versus:
function setOptionsCallback()
{
console.log( 'object created' );
return {};
}
In the end, though, most of these problems can be overcome with some good defensive programming and solid documentation.