I remember having seen a slide from the Maemo summit on flickr (can't find it right now) that said something like "normal boot sequence; no initfs" or so about Maemo 5.

First I didn't care much (I was looking for pictures of people), but now I wonder:

1.) Why is the boot process the way it is? Is it safer this way? Is it because of legal problems with closed components?

2.) What's the advantage of changing it? Will it be faster? Will there be things you can do that you cannot do now?

I actually prefer the initfs way somewhat - it gives possibility to use other distributions and also that we don't rely on the rootfs - rootfs can be fried and unbootable but initfs is static and often working.. But I'm looking forward to see how Fremantle handles it.

any time table for fremantle

There isn't actually much point in using initfs when you're on known hardware.

Initfs is mostly useful for traditional distributions where you have a generic kernel with most drivers as loadable modules. Then you boot from a ramdisk image (part of initfs), you do some hardware detection, you can then go on and load (from that same ramdisk) the drivers you'll need to access the actual root disk, e.g. scsi driver? or IDE driver? Or SATA driver? And filesystem driver: ext3? Reiserfs? and so on.

That way you can have a lean, mean kernel (due to drivers not compiled in, but being loadable modules), and load the drivers you need at runtime. Obviously that wouldn't be possible without initfs, because you can't store the disk (well, SD) and filesystem drivers on the root filesystem you haven't mounted yet.

However, when the hardware is known you simply compile in (as in 'part of the kernel, not dynamic, loadable') the minimum set of drivers you know you need (to be able to load the root filesystem), and you can skip the initfs step. (When I install a system on a desktop I usually make a new kernel for myself , without initfs).

Good questions :-)
It is safer this way because initfs is not used for writing so less things can go wrong with it. Rootfs can become corrupted or full. Current initfs also contain some factory hardware self testing stuff and is small so it is faster to flash/boot and test the hardware.
initfs is compiled with uclibc tooolchain for space reasons so it is slightly more complicated for development (two versions of libc and gcc and busybox - more possibilities of bugs, more testing needed). Also it proved itself to be more cumbersome for SSU and is harder to resize when space gets tight in it.

I guess the reason for change is that OMAP3 boot ROM (directly on the chip) has 'unbrickable' design and can load main bootloader straight from nand,usb,serial and mmc so some reasons for having initfs partition are gone.
As for faster boot - well, it may be slightly faster but not significantly.