I know there's a lot of history in function files, but I haven't used them for decades. My primary reason (and I assume many others) was to keep the workspace size down to something that can be )LOADed. With workspace sizes now measured in gigabytes (and soon to be exabytes), that reason has really gone away. I'm sure there are old applications that still do this that you want to maintain, but I can't see anyone changing the way they do this just because there's a new feature available.
You also mentioned other reasons to have function files, but I don't see that any of them can't be reasonably fixed in other (programmable) ways. For instance, if you're worried about FF code that doesn't do the job well, then pick a tool that works (without defects) and use it. I have a set of tools that I called my "cf" utilities, for instance, that I think does a great job of handling named component files which are ideal for FF storage (which mostly uses only a single standalone function, so as not to clutter the workspace itself). But anyone that puts together a nice system can distribute it and everyone's problem is solved.
For keeping utilities synchronized, normal APL processes should be sufficient without invoking new languages features, and it wouldn't even be necessary to use function files. For one example (and others are feasible), several years ago I wrote a system called ARM (see recent public distribution in
http://forum.apl2000.com/viewtopic.php?f=7&t=1209) that helps you manage application code. It includes a "toolkit" facility where updated tools are automatically distributed to all the applications that use them. I've been using nothing but that for nearly 7 years now and find it to be a wonderful solution to this problem, but anyone can write their own auto-distribution tool if they have a mind to. ARM, BTW, should be able to run in APL64 with no or trivial adjustments.
As for cluttering the workspace, I don't see much of a problem with that. Very many times I want to use my utilities from the session and surely don't want to have to fetch them first (or else I'd use )COPY). My utilities (which may be an exception) rarely have subroutines, and APL64 will generally get rid of that need anyway with :DEF. I also use more utilites, more often, than anyone else I've seen, so I'm probably an extreme case.