Typically, my preference for a particular type of technology or architecture is driven by the nature of the task I need to accomplish. I favor that which gets the job done most efficiently and allows the project to be maintained most easily. I can't think of any situation in which I would recommend using ColdFusion pages rather than ColdFusion Components to provide Flash Remoting services. Using ColdFusion pages and the Flash variable scope might be faster initially for developers not familiar with CFCs. However, I strongly recommend learning to write CFCs and appreciate the theory behind them.
There are three things CFCs offer that ColdFusion pages do not:
CFCs provide an excellent and completely automatic form of documentation, and you can browse them from the Flash and Dreamweaver authoring environments.
Since CFCs allow you to define the arguments that a function accepts, the ColdFusion Server can automatically validate the parameters passed to a function. You must hand-code such validation for ColdFusion pages.
Writing Flash Remoting services as ColdFusion pages requires the Flash variable scope for retrieving arguments and returning data, making the pages incompatible with clients other than Flash. ColdFusion Component code can and should be kept generic enough that you can invoke the same functions from various clients, such as Flash Remoting, ColdFusion pages, other CFCs, and through URLs.
Some advantages of CFCs can be simulated with ColdFusion pages, although it often requires additional work. For example, the clever use of includes can achieve the same result as inheritance and allow a high degree of code re-use and modularity. A set of well-planned ColdFusion pages can be maintained easily and can provide the same level of encapsulation as CFCs. Although each developer must make his own choice, CFCs were designed with advanced, object-oriented development in mind, whereas the same concepts are afterthoughts in the context of ColdFusion pages.