The archetype of a CEP engine would be something like Esper. You can fully embed it in an existing runtime (Java or .NET/C# for NEsper), ranging from standalone JVMs with bare metal thread pools to JEE application servers or SOA stacks.
The archetype of a CEP platform would be something more like Streambase, or the Oracle CEP server or well you name it - where the product is a server - no choice - sometime even worse with a whole bunch of dependencies (for example a relational database and/or a mandatory JEE application server - see IBM Business Events for example).
I am firm believer that there are numerous technical advantages of getting started with Complex Event Processing using a CEP engine.
Check out the Esper examples (one integrates with JMS f.e. TibcoEMS, another with JBoss, etc) or the growing list of ISVs embedding Esper into their own solutions - from asset tracking, network security and trade platforms of all kinds.
More control and flexibility and more reuse of your existing investments.
This also fits well if IT, speed and flexibility is a competitive advantage - which for example was echoed in a recent WallStreet & Technology article:
Wall Street Opens Doors to Open Source Technologies
"Esper is already built. Instead of being a standalone server product that runs as a separate product, it's a library that you link in with your own proprietary stuff. That way you don't have to worry about another additional process." (an industry source who is involved in the development of trading systems at a major investment bank)
Needless to say, things are not black or white. I am also a firm believer that there are numerous long-run advantages of scaling up your CEP use through a CEP platform approach. Enforce shared practice for monitoring, high availability, deployment unit management and consistency across projects.
Interestingly, Esper tackles this through its (commercial) Enterprise Edition - with bells and whistles around management, tooling and high availability.
More enterprise *ilities and more wisdom long run - likely.