I have an application that interacts multiple databases and some custom services. For some operations, I need transaction-like behavior where a set of changes either commit acro
It does its job and there is no accepted alternative. If you must use distributed transactions, then there is no way around XA.
It is "standard technology", no hype and no marketing. Therefore it flies below the radars of most people.
Even when it is used, there is a good chance that Jack Application Developer does not know it as most parts are usually hidden in some frameworks.
The need for XA is indeed somewhat on decline, because Service Oriented Architecture (SOA) and message queuing are hyped architecture paradigms which try to avoid such tight coupling of subsystems. Although at least SOA also seems to be declining quite well. ;-)
Often forgotten parts of XA are the required code and tools which are used when a transaction actually breaks. There are some outskirts in XA where the Transaction Manager can neither commit nor rollback all resources for quite some time. This point only increases the "use it only if you really must" point.