The rationale is that the createdCallback is like a constructor and should run to completion before callbacks start firing.

However the callbacks should still be queued (not dropped) while the createdCallback is running, because that is past the point where the prototype has been updated.

For example:

proto.createdCallback = function() {
  console.log('created start');
  this.remove();
  this.setAttribute('foo', 'bar');
  console.log('created end');
};
... (other callbacks which log) ...

should log

created start
created end
entered
left
attribute changed

Maybe the relationship between enqueuing a callback in a callback queue, and moving the callback queue to the top-of-processing stack element queue needs to change. Maybe the spec should model this with an explicit flag (
("created-callback-ran"). If the flag is not set when enqueuing a callback (other than the created callback and the special-case first entered callback), then the callback queue should not be moved to the top-of-processing-stack. (Of course no callbacks are queued until the created callback has started running, as usual.)