You can read the following in the CForm documentation:
... we can divide the form in two parts: those that define each individual input of the form, and those that adorn the input of the form. The CForm object represents the previous part ...
... and CActiveForm represents the latter.
In other words, CForm points to form elements, but CActiveForm (being widgets) does this.
Considering the source code, we indicate that CForm can also render () itself, and its rendering is based on and wrapped by CActiveForm by introducing its activeForm configuration property , although the rendering of input elements and buttons is implemented by its own renderElements () and renderButtons () methods relative. By default, their implementations rely on classes using CHtml static methods, which is the same (or almost exactly the same) that CActiveForm rendering methods do. Of course, the default behavior can be overridden by extending the class.
That’s why the question of taste, which method to use: CActiveForm only a widget that combines the declaration of form fields and buttons with their representation in the view file by calling the convenient (necessary) instance methods of CActiveForm or CForm class declares the form input specifications in a separate configuration file and sets up its rendering , pointing to the corresponding widget of the active form and / or overriding the default rendering methods. The latter method makes it easy to use the form in several actions and no more than using the form builder .