There is no guarantee that any Mailman Core installation into which a MM 2.1 list is imported actually also supports Django users for Postorius and/or HyperKitty.
There is no guarantee that a mailman-core installation also includes Postorius and/or HyperKitty. However we can imagine that the vast majority do utilize all those components. If you've installed mailman3, you are probably installing Postorius and HyperKitty. To account for the fact that it's not 100% guaranteed, the import script could require a flag such as --django-accounts. Or it could even be another script entirely. So, the step wouldn't be automatic, but at least it would be an option.
inherently not secure
The passwords were good enough for mailman2. If a mailman2 instance has been in production for 20 years and users aren't complaining about security, maybe it's not a show stopper. The point is to make the upgrade seamless. That means... being able to say that everyone gets to keep their user account and password. To be able to easily tell the users "Your account is still the same. Just log in. Change your password when you like."
In the current context, passwords are associated with django accounts rather than mailman-core accounts. So this is about creating django users.
creating a django user is "expensive". "poor performance"
I didn't follow what that means. What is expensive? What is poor performance? Creating new django accounts en masse would be a one-time operation. It doesn't matter if it's slow, or expensive, since it only happens once.
And it would be optional. With the --django-accounts flag. Or another separate script. Then you can tell users "Your account is the same as before. A transparent upgrade. Just log in".