We've begun using the flash form of the cfform tag to prototype UI's that will eventually be built in flash. While you cannot duplicate the functionality of a flash UI with remoting and listeners etc., you can get pretty close to duplicating the data and UI display. Let me explain.
We have an application that will eventually use custom made UI's built in flash. There are still many good reasons to use the flash IDE to create such UI's. For example, suppose you want to implement a behavior that counts the number of characters typed into a combo box and when the 3rd character is typed you want to pre fetch data (using flash remoting) to fill the box with possible options. There's not way to do that using CFFORM - the data has to be pre-loaded. The same is true of the grid control. The grid is extremely useful for displaying search results that click through to a detail page. Without "pre fetching" the data and sorting through it on the client side there's no way to do this using CFFORM.
There are many other examples, but here is one of my favorites. I like to create a "helper" object in the side bar that is a flash movie. It contains a text object and a couple of placeholder clips for thumbnail images. Using the localConnection Object I can add context sensitive help to a flash UI. When a user "rolls over" a button or calendar (or whatever) I can display helpful information in the side bar movie. There's no way to duplicate this in cfform. Actually I was able to mimic the behavior (sort of) using the shared object, but only because you can build a shared object without needing to use the "new" keyword. Plus, this "work-around" requires that my helper object constantly "get" the shared object and check it to see if it has changed.
The point is, the new flash format of CFFORM doesn't replace the use of flash and web services or remoting. However, it can be effectively used to prototype. What do I mean by prototyping? For us it is part of the process of joint application design. We meet with the clients and stakeholders and initially determine their needs. From that meeting comes the initial requirements document. From that document we create, as a first step, a number of prototypes representing all or most of the screens that the user will be using. Normally we use HTML To do this - even if we are eventually going to work in flash.
Using HTML means, that while we can duplicate the data bits and general flow of the screens and behaviors, the final "look" will likely not be represented. Using CFFORM with the flash format however we can indeed get much closer to what the user expects. In particular we can add tabs, accordion views, grids, rudimentary validation (love the validation tip windows and halo outlines - that is the stuff), and calendars for date choosing. The look will not perfectly mimic the final outcome, but it can get pretty close. Close enough to be a pleasant surprise when we do that prototype review meeting with stakeholders. They are generally pleased by the ascetics and functionality provided. And best of all, it takes no more time to do it in CFFORM than it does in HTML - so we get the best of both worlds.