All changes mentioned below happened in the Developer's Guide, Creating a new task chapter.

1) Added a note about the use of the tx_scheduler_Task constructor

If the task class uses a constructor it is absolutely necessary to include a call to the parent's constructor, most probably as the first thing inside the constructor, unless there are some very special reasons not to:
class tx_myext_mytask extends tx_scheduler_Task {
	public function __construct() {	
		parent::__construct();
			// Your code here...
	}
}

2) Added a note about properly naming the additional fields to avoid errors and conflicts:

Naming of additional fields
The Scheduler expects all fields in the add/edit form to be named tx_scheduler[...]. Values from fields that don't follow this pattern will not appear in the $submittedData array.
It is also important to think about using field names that will not create conflicts with other existing fields or future fields that may happen. Since there is no name-spacing mechanism available, it is up to each developer to choose proper names. A very good practice is to prepend the extension's key to the additional fields names in order to guarantee the unicity of those names.
Bad examples
Here are some examples of bad additional fields names:
foo
tx_scheduler[name]

The first name doesn't use the syntax and thus will not be handled by the Scheduler. The second one respects that syntax, but the name is too generic and may cause conflicts with other fields.
Good examples
Here are good examples of additional fields names:
tx_scheduler[myextension_myvalue]
tx_scheduler[myextension][myvalue]

In both cases the proper syntax is used as well as the extension key, making it very unlikely that a naming conflict could happen.

3) Added advice and words of caution about working with serialized objects:

Working with serialized objects
When a task is registered with the Scheduler the corresponding object instance is serialized and stored in the database (see Appendix A for more details). This is not a very common practice. There are advantages but also some pitfalls, so please read this section carefully.
A serialized object may happen to be “out of sync” with its class if the class changes some of its variables or methods. If a variable's name is changed or if variables are added or removed, the serialized object will not reflect these changes. The same goes if a method is renamed, added or deleted. Problems will also arise if the number or order of arguments used to call a method are changed. In such cases weird errors may appear, which can be very difficult to track. The only solution is to delete the registered task and register it anew.
To minimize such risks it is worth to consider implementing the business logic in a separate class, so that the task class itself changes as little as possible. The execute() should be as simple as possible. Consider the following:
class tx_myext_mytask extends tx_scheduler_Task {
	public function execute() {	
		$businessLogic = t3lib_div::makeInstance('tx_myext_BusinessLogic');
		$businessLogic->run(arg1, arg2, …);
	}
}

In such a setup the execute() is kept to the strict minimum and the operations themselves are handled by a separate class.
Also remember that the constructor is not called when unserializing an object. If some operations need to be run upon unserialization, implement a __wakeup() method instead.