All inputs in html only fire change events after they have been blurred. GWT follows these same basic semantics, as does GXT - the ValueChangeEvent denotes that the user has finished editing the field, and has left it.
That said, ValueBaseField also supports a getCurrentValue() method that attempts to read from the field while it is still being edited. This isn't implemented for all Fields - it doesn't always make sense to expect a value to be read out at any time - but for fields usually implemented with an text input (i.e. ValueBaseFields), it is possible to read out the value, parse it, and return it through getCurrentValue().
Selection is a slightly different matter - we use this event to indicate that the user has made some interaction with the field, using the keyboard or mouse, and wrap these physical interactions up to be a logical intent. It is possible to use a SpinnerField or ComboBox without causing Selection events (only typing in the input), and it is possible to cause selection events with the mouse and keyboard (usually arrow keys). These are discrete changes to the field's state, but not yet value changes (which, as mentioned above, involve a blur). More precise physical events can be detected by adding Click or Key handlers to the widget as well.
All GXT Fields that can be used in a Grid or other data widget are implemented using Cells - this is done to make them usable in any cell widget, whether written by Google, Sencha, or any other GWT-based library. This is a somewhat restrictive API, and its limitations have introduced interesting issues in how we still support GXT 2 functionality, and leave room for teams using GXT to go forward and build even more features. One of the chief ways that widgets are often improved and augmented is through events, but making events consistent with the ability of a Cell to be rendered in many places at once can be difficult. GWT doesn't address this at all, so we generally use the HandlerManagerContext to allow a cell to dispatch events out through the Field that wraps it, or, if no HandlerManagerContext is available, to fire just from the cell itself.
GWT's own SelectionEvent is written such that you must use a static method to fire it - there is no way to ask it to be fired from multiple sources, as can be done with almost all other events. Our first attempt to deal with this was to copy the class and change its implementation to be like other events, able to be constructed and fired normally, but from discussions with the community, we took the approach of extending GWT's SelectionEvent as CellSelectionEvent - firing in much the same way, but able now to be dispatched to multiple sources. This has now been released as part of RC2.
So in conclusion, changing value doesn't necessarily imply that selection has occurred, nor does selection imply that the user has finished and left the field. We try to be deliberate in our API choices, especially where we are going beyond what stock GWT events and APIs generally make possible, and we welcome and try to respond to community feedback.
If you are able, I would welcome you to join us on irc.freenode.net in #extgwt to continue this discussion, or others. Not all organizations (or schedules) permit IRC, so we'll of course also continue these discussions on the forums as well.
Select an item (for example, Arizona) from the first list, and then observe what happens to the ComboBoxCell display value on blur of the ComboBox. The display value changes from the intended display text to what appears to be a toString() of the cell's object, resulting in an object reference string being rendered in the cell, instead of the normal display value.