Layout Components is certainly not the only solution to handling layouts, but others have weaknesses not found in Layout Components.
Most ColdFusion MVC frameworks are more a positive than they are a negative to overall development. For specifically dealing with layouts, however, they are overkill.
Most ColdFusion MVC frameworks (including Fusebox,Mach-II,Model Glue) are hub-and-spoke, meaning that all requests are forced through one file (usually index.cfm). This is another topic unto itself, but that is a potentially high price to pay for dealing with layouts (if, on the other hand, you are looking for more than just layouts, investigate any of several good ColdFusion MVC frameworks).
CFINCLUDE is the simplest (and certainly most performant) way to handle layouts. This approach, however, requires each layout to be split among two files (three if you want to handle the HEAD easily), making editing for the design difficult.
Straight custom tags (where the opening tag outputs the beginning HTML and the closing tag outputs the ending HTML) are a very easy way to handle layouts. They also have the added advantage of keeping each design in one file for easy editing.
This approach, however, leaves to place for easily placing the content into the HEAD. Nor does it allow for easily switching layouts without some other mechanism.
Outputting HTML from Application.cfm (and OnRequestEnd.cfm) or from Application.cfc (either directly or indirectly) seems like the simplest approach. It circumvents the need to have any code in each file to handle layouts.
The problem is that as some files need to have different layouts (or none at all), all of those decision must be made in the Application file itself, without even the benefit of variables being set on the page itself. Over time this will lead to a very difficult to use Application file.
Putting HTML in the HEAD also remains difficult.