Summarizing below for tl;dr.
:
- While it is flagged in the validator, since Lemmix doesn't actually make it compulsory, it's likely there are custom levels out there that already have made used of non-multiples of 8 in interactive object's x, making it somewhat necessary for other editors to support it. From what I can tell and recall, objects with such x values still work well enough in both Lemmix and even the actual DOS programs (ie. DOS Lemmings, CustLemm, etc.) that chances are good that no one even realizes it's an "issue" for such levels.
- For steel areas, IIRC even the level file format itself cannot represent steel area x and y as anything other than multiples of 4, so there's nothing to fix or debate here.
- Level starting screen x position: I'm not sure how exactly it will behave in DOS, but I know for sure that the game mechanics governing how lemmings move and interact in the level never uses that value, and I'm guessing Lemmix doesn't behave any differently whether it is multiple of 8 or not. So like object x, you may have to support it by virtue of existing custom levels out there already having made use of non-kosher values here.
[Aside: as explained below, the multiple-of-8 for object x is really an artifact of how pixels are organized in memory in the display mode used by the DOS game, and it really only comes into play when displaying the object on the screen. This also means that if you use one of the other graphics-mode variants of Lemmings like CGA/TGA, they may well support slightly different visual display alignments for object x. (Granted, I have not tested this at all or disassemble the programming in much detail for the CGA/TGA EXEs, so this is just an educated guess.)]
==========
IIRC (could be inaccurate as it's been a while since I actually tested things out or looked at the code), in the actual (DOS) Lemmings game (including varieties such as CustLemm), if you set an interactive object's x position to a non-multiple of 8, the game will still position (visually) the object visually at the highest multiple of 8 not exceeding x (ie. nearest on the left of the true x). This is really an artifact of how pixels are laid out in memory in the video display mode used by the game. This is probably why rt documented the x position "must" be a multiple of 8.
But, calculations of trigger areas actually use the true x value but is subjected to the usual snapping to multiples of 4 as mentioned by Simon (ie. applied after adding the object's trigger position offset from groundXo.dat), and trigger area effects should still work. In that respect it's basically no different than trigger area's y. Calculations of "entrance locations" (namely, where exactly a lemming is initially placed in the level when it comes out of a particular entrance trapdoor object) uses the true x (and y) value as-is.
AFAIK Lemmix doesn't emulate the part where the visual display position is snapped to multiple of 8. But I think it handles the rest just like the real game, and since the visual display doesn't affect gameplay (ie. results with respect to Lemmings and moves), levels using non-multiples of 8 for object's x position should still "work" as far as solutions and emulation accuracy go. Still, given that the objects won't be displayed at the exact correct locations in CustLemm and so forth, it is not a bad idea to avoid using non-multiples of 8 for object x positions to avoid confounding users of CustLemm and similar, just like the official levels avoid. Lemmix currently flags this as an error if you run object validation, but it is not compulsory and since both the level editor, the level file format and its game emulation all handle it well enough, I'd expect a number of existing custom levels to have made use of non-multiples of 8 for object x as a result.
Steel areas are handled as a different type of element than interactive objects. IIRC the level file format itself only allows steel areas' x and y positions to be represented in multiples of 4, and inside the game it is handled through the 4x4 pixels square grid that Simon mentioned. Thus they are effectively "moved" to multiples of 4 as soon as you play or save the level, like Mobius observed. Ideally Lemmix really should never allow steel areas to be positioned out of the 4x4 grid alignment within the editor.
I don't remember how the starting screen position of the level behaves in the actual DOS game if you don't set it to a multiple of 8. On the other hand, Lemmix probably (don't remember for sure off top of my head) doesn't enforce any constraints on that value and likely will handle it normally like multiples-of-8 values, so again you may have some custom levels that already have used non-multiples of 8 for starting screen position.