etex package should be safe in almost every case. It's main aim is to alter the allocation scheme to use the extra space made available by the e-TeX, and it does this in such a way as to avoid as far as possible any conflict. (Note that the team plan to enable use of the extended registers in a format release but this will use a subtly different approach to the
etex package.) As to whether you need to load
etex: only if you find yourself running out of registers. The idea here in adding to the format is that this will free both package authors and end users from worrying about this.
fixltx2e is a bit more tricky, and indeed the team are working to ensure that this can be 'backed out' of the format once it is built in as standard. The changes in
fixltx2e are not currently in
latex.ltx as they in some way change behaviour. Some of that is nowadays not too much of an issue: for example, making
\) robust uses two additional csnames, which could not go into the format when the issue came up (at the time this could have pushed some people's documents over the edge in terms of name use). Other changes in
fixltx2e may alter existing documents in some way, and that is more tricky. (For archiving reasons, some documents cannot have any changes at all in output.) That said the content of
fixltx2e is all stuff that arguably should have been in the format when released in 1994. As noted in another answer, it's quite possible never to run into a need for
fixltx2e. As to whether you should load the package: I'd argue 'yes' as these are things that really should be fixed. However, in many cases you might not notice the difference.
That brings us to the question of why the team are looking to add the functionality here to the standard kernel. In the
etex case, neither users nor package authors really should have to worry about enabling an extended allocation scheme. The format should have some 'awareness' of the capabilities available and use them. In terms of
fixltx2e, as already noted this is stuff that should have been in the kernel anyway. What adding it will bring is that users won't have to know about the cases where it's useful and package authors should be able to predict more readily the form of certain commands (for patching). There will be a mechanism to reverse this inclusion: there are a few cases where the fixes alter outcomes rather than avoiding out-and-out error, and those are important for the archival stability side of things.