I would say it is "by accident".  The modifier value of 16 is the same as
InputEvent.BUTTON1_MASK, which just indicates that Mouse Button 1 was
pressed.  You really cannot count on that always being the case.  For
example, the user could use a different mouse button, or could hold down
the Control, Shift, or Alt keys when he makes the selection, which would
result in a different modifier value.  Also, how the selection can be made
is look-and-feel dependent, so it is possible that some other key could be
used.  Add assistive technologies into the mix (voice commands and other
specialized devices), and you really cannot know how the selection will be
made.

The problem here is that, despite the fact that JComboBox provides support
for ActionListeners, it really supports a selection paradigm rather than
an "action" paradigm.  It provides gestures to change the choice, but not
one that indicates a final choice.  Nothing says "I've made my choice, so
go do it", whatever "it" is.

The Swing designers certainly could have designed the JComboBox that way,
but they did not do so.  Grafting this behavior onto a combo box, using
the existing actions will cause problems.

The component that best supports actions is the JButton, so perhaps it
would be better to place an "Add Word" button next to the combo box that
actually adds the word.  You could also provide a hot key to perform the
add word function.