Page.Title = "History";
Page.Name = "history";
Page.FilePath = "about-us/history";
Page.Feature = "PageDisplay";
etc. . . .
Originally, page stubs were just a way to avoid problems I was having getting URL rewriting to work on IIS back in 2001/2002, but now as I revisit them, I see them as a potentially interesting way of decoupling the process of generating URLs from the process of consuming them . . .
When you just want one page for each record in your database, there is no real reason to use page stubs (other than as a backup if you can't get ISAPIRewrite to work!). Just use URL rewriting to turn /a/b/c.html into index.cfm?filepath=a/b/c and then Page = PageService.getPagebyFilePath(filepath).
However, what happens if you want your catalog feature to be able to generate URLs for each category and product or your events feature to be able to create URLs for every event? As you end up with n-features - potentially written by a number of different developers, getting the URL rewriting to map a URL to the appropriate resource could get pretty hairy and you'd have to have some kind of lookup for each object supporting filepath based access. You could use a RESTful approach, but that is a technical convention that doesn't always meet the needs of users to have the new product available at /new-category/special-subcategory/new-product.name.html rather than at just products/new-product-name.html.
By using page stubs, all you do is write a page stub generator for each feature that requires one (if it has multiple pages that each need to appear like a different html file - if you only need query string parameters to access a resource in that feature then this is not relevant). They all extend a core stub generator so general conventions like the file extension and the properties and formatting of a page stub is controlled in a single place (BasePageStubPublisher) making it easy to modify as the properties describing a page change over time. You define a page in such a way to support the setting of certain properties if they haven't been set via URL or form (so you can pass a Catalog feature a product ID and a screen type to use, for example) so that many URLs can easily call the same feature but with different default properties (so /new-category/special-subcategory/new-product.name.html becomes equivalent to index.cfm?page=catalog&action=productdetail&CategoryID=12&ProductID=712).
There are definitely downsides to this approach, but I have a bunch of sites using the basic principle (I think I started doing this about five years ago) and I think this is powerful enough to be worth spending an hour or two writing some simple generators for core pages and the catalog feature to see how well it works out.