> I've been running into this lately too.  I intend to look into it,
> though any further investigation from you would be much appreciated.

The issue starts at 2f3cf7ffe3c9ce986caf6d093b880fed6046b7ec, whose
purpose (bug#15645) was to have C-a take us to the start of the field
rather than the the start of the line.  Reverting log-edit.el to any
prior commit resolves the issue.

The issue is that after inserting the headers with

(propertize (concat header ": ")
            'field 'header
            'rear-nonsticky t)

any typed text inherits the (field header) property, but yanked or
inserted text does not, introducing a field boundary that obstructs
forward-word.

Removing these properties like in the patch below addresses the issue,
but I'll confess that I don't understand why these properties were
introduced; I hope someone that does can analyze further.  Indeed, I
haven't been able to reproduce bug#15645 after evaluating older versions
of log-edit.el, so maybe something relevant outside of log-edit.el has
changed in the mean time, but C-a is bound to
log-edit-beginning-of-line, which is a light wrapper around
message-beginning-of-line, which has had the "beginning of header"
feature since many years before bug#15645, so maybe I missed something.