The key is your requirements. If you're replacing an existing ESB, how are you currently using it? How would you like to use it?
We, and other gateway vendors, have long and successfully positioned our gateways as special purposed ESBs (or ESB gateways, or NoESBs to use the term recently coined by Gartner; see above). By that, we mean we focus on the 20% of ESB capabilities that give most customers 80% of what they want/need from an ESB. That 20% is what ESB vendors largely agree is the core capability of an ESB, service virtualization. We support service virtualization of identity via routing, protocol via bridging, and interface via transformation; and we often do these things quicker, easier, and better with better security, performance, scalability, reliability and a lower total cost of ownership over time.
For service virtualization of identity via routing, we provide simple and sophisticated, accelerated and dynamic, runtime routing based on context and content.
For service virtualization of protocol via bridging, we provide support for and bridging between different combinations of inbound/outbound HTTP(S), FTP(S), SFTP, SCP, JMS, MQ, AMQP, Web Sockets, XMPP, APN, SSH, Raw TCP; inbound IMAP, POP; outbound SMTP, SNMP, JDBC, Cassandra and custom Java protocols.
For service virtualization of interface via transformation, we provide accelerated XML-to-any transformation with XSL; JSON to/from XML transformation with an out-of-the-box assertion; and any-to-any transformation with custom Java, Contivo and Data Direct assertions.
If your requirements fall within what we do well, you will realize a lot of value using our gateway as a special purposed ESB.
That said, we don't usually try to replace a customer's existing ESB (unless they ask us to, and they're using their existing ESB only for requirements that fall within what we do well, and they like our value proposition more). There are things that most broadly capable ESBs have/do that we don't. For example, they tend to have many adapters to handle esoteric protocols that we don't (though we support the most common ones). They tend to include queuing systems, and we don't (though we can connect to queuing systems when they're provided). They tend to support transactionality, and we don't (though we can support composite transactionality in policy). They tend to layer on higher level capabilities that some would argue go beyond the ESB itself, like long running orchestration, and we don't (though you can perform some orchestration in policy).
More often, customers with existing ESBs will also get our gateway for the things it does well, which let's them avoid their complex and expensive ESB more of the time, while they keep it around for the few things they use it for that only it can do.