* Components have a support for customizable UI interfaces for setting the property of components called property sheets and these property sheets are applicable on a component level or at the level of individual property fields in the component. These property sheets show up when you are trying configure a component in the design mode within the IDE. We are not talking about simple text entry type of fields - you can actually do very sophisticated property sheets with tabs, multiple forms etc and what not. It is EXTREMELY configurable and also relatively easy to develop.
* Delphi uses a binary "form" file into which each GUI form persists its interface. So everytime you place a component on a form in the GUI IDE or set its properties, the form and its components have a way of persisting their values into this "form" file. The reverse also happens - so when a form is loaded into the IDE or during runtime, the form fields are read off the "form" file by the form and its components. So the actual .pas file where you are adding code for the events etc is not filled up with a lot of UI related property setting code and so the code looks really clean with clear separation of design and code.
* Components can be installed into the IDE during development very easily
In Free Pascal (and Delphi) all classes have a "metaclass" (a class that describes the class) and can be used in conjunction with the RTTI to obtain information about an object at runtime - including its actual class, exposed properties and any optional metadata (like attributes in FP).
This functionality is used by Delphi/Lazarus to serialize and deserialize objects on disk (the form files you mention are such serialized objects but you can serialize other types of objects and in Lazarus -perhaps Delphi too- you can use several file formats) as well as implement the object inspector.
In a way Delphi/Lazarus work kinda like how game engines like Unreal work in that you are working with "live" instances of objects, using generic object inspectors and saving them on disk is done by serializing them (though obviously it is the opposite since Delphi predates most game engines using this approach :-P).
The important aspect with all the above isn't so much the form/component serialization but the language features that make it possible in the first place: metaclasses and RTTI that provides enough information to instantiate and describe objects and classes at runtime.
My own game engine[0] is written in Free Pascal and Lazarus and uses the exact same language features to provide object serialization, property editing and some other stuff (like object diffing that is used for many undo/redo operations). Instead of TComponent/TPersistent (the types Delphi/FCL provide for serialization), it has its own base types that use a more compact file format, optional compressed streams (e.g. for texture data) and external references (for shared assets stored in separate files), but still relies on the same base functionality provided by the language/compiler.
