Strange [number]s in Delphi DFM files - origin and necessity?

Those numbers aren't completely useless. Let's say you have classes TA, TB and TC, and TB and TC both derive from TA. The DFMs look like:

object A: TA
  object X: TX
  end
end

inherited B: TB
  object Y: TY
  end
end

inherited C: TC
  object Y: TY [0]
  end
  inherited X: TX [1]
  end
end

B and C differ in that the order of their X and Y subcomponents is reversed. The precise meaning of subcomponent order depends on the components (see below), but most notably, if they're TWinControl descendants, or they are both TControl descendants that do not derive from TWinControl, that means they differ in whether X is shown over Y, or Y over X.

Removing these numbers may change the forms, so you shouldn't blindly do it. However, depending on your goal, you may be able to modify the parser (source code appears to be available) to simply skip over the numbers.

The relative order of components generally does not generally matter much, but there are a few exceptions. To explain in some more detail:

For normal controls, the subcomponents start with (1) TControl descendants that do not derive from TWinControl, then (2) TWinControl descendants, finally (3) any non-TControl components. In each of these, the relative order of components is adjustable: for controls, the "Bring to front" and "Send to back" move the control as far as possible, with the limitation that a non-TWinControl can never be put after a TWinControl. For non-controls, the (slightly misnamed) "Creation order" option allows you to change the order. So, let's say you have two labels (A and B), two edit controls (C and D), and a dataset and data source (E and F), you can get the order to be for example, ABCDEF, BACDEF, ABDCFE, but not ACBDEF.

That order is preserved when saving to a DFM file: when visual inheritance is not used, components simply get saved and re-loaded in order. When you do use inheritance, the DFM files get processed base to derived, so in the above case, when TC is created, its X member is always created before its Y member. The [0] and [1] are needed to tell the Delphi RTL to fix up the order afterwards, in those cases where the component order matters.

What the component order actually does depends on the component type. As the "Bring to front"/"Send to back" names suggest, controls use the component order to specify the Z order. For other component types, it means whatever the component wants it to mean. For example, menus can use the component order to specify the order of their menu items (top to bottom). Toolbar controls can use the component order to specify the order of the toolbar buttons, even when those toolbar buttons aren't themselves controls. Data sets use the component order to specify the field order, and thereby also the default order of columns in a TDBGrid.