You are right - this is by design. SMIGRATE or FP Migrate (which is GUI to
the same tool) is not designed to carry over any personalization or
security/permissions. They all get dropped out.

Use STSADM Backup/Restore for a full fidelity move of site  from Point A to
point B. Also note that STSADM only works at Top-Level Site (including all
sub-sites). You cannot use it for a sub-site.

There was a discussion about this deal few weeks ago on this group that you
may found useful.

Mypoint was, why then does the backup  take alerts  across....surely a
cleaner approach is to not take any user  related content/config across ?

That is interesting if users are getting alerts  from migrated sites.
I am not at a place where I can test it but based upon what I know and
experienced I would include Alerts as part of user  related thing which
should not be carried over (unless it is a v1 to v2 upgrade). Following is
an extract from WSS Admin Help. It does not mention Alerts explicitly but I
would imply Alerts as well.

Migrating Windows SharePoint Services Sites to Another server  Running
Windows SharePoint Services
If you use the SharePoint Migration Tool to migrate a site  based on Windows
SharePoint Services to another server running Windows SharePoint Services,
the following information is not migrated to the new site:

Security settings including: rights, site groups and memberships, cross-site
groups, anonymous access setting, and whether or not permissions  are
inherited from the parent site.
SharePoint Central Administration settings for the server or virtual server.
Personalizations including personal views.
Web Part customizations made through Modify My Web Part instead of Modify
Shared Web Part.