When should you use OMSourcedElement instead of a fully built OMElement?

Reach for an OMSourcedElement-backed approach when the canonical form of your data isn't XML to begin with - a Java object graph, a JAXB-annotated bean, a result set - and you want to avoid converting it to XML unless that conversion is genuinely required.

This pays off most clearly in pass-through message processing: in an Axis2 pipeline, for instance, a message might flow through several phases untouched before reaching a downstream consumer; if the body is represented as an OMSourcedElement wrapping the original object, the object-to-XML step only happens if and when the body is actually serialized onto the wire, rather than being done speculatively for every message regardless of whether it's needed.

By contrast, when your source data genuinely is XML bytes to begin with - a request received over HTTP, a file on disk - or when the application needs to freely mutate an arbitrary tree structure (adding, removing, or reordering nodes at will), a normal StAX-parsed or OMFactory-built OMElement is the right fit, since there's no conversion to defer in the first place.

A useful rule of thumb: OMSourcedElement is about deferring a conversion, not about deferring parsing - if there's nothing to convert from, it doesn't offer any benefit over a normal element.