In the past it seemed like a good idea to try to make use of slight difference between logically equivalent cases of:

<root>
   <empty/>
   <start></start>
</root>

so that empty would be automatically exposed as null token; whereas start element would have non-null empty String.
This was the behavior until 2.9: 2.9 introduced FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL to control whether this should be done or not: if disabled, both were equivalent, exposing them as start-end pair regardless.
This is more compatible with the logical content model of XML, but default was left as "enabled" for backwards compatibility.

However: with 2.12 there is much better support for various things:

1. Exposing xsi:nil attributes for true nulls (added in 2.10.0)
2. Allowing flexible coercions from empty String into "empty" POJOs, collections, maps

so it seems much more likely that users find defaulting of this setting to false as the right behavior.

I realize that change in behavior can cause issues but in this case I think change is warranted: it is also what 3.0 is planned to use.