But when you have a smart editor such as emacs, with at least a good
search function, or even a find-tag feature, it doesn't really matter
where your functions are stored.

I use emacs, and I am not thinking about searching functions, which has been also repeated to me privately as a reason (!) to have everything in one file, but rather in organizing the code and giving it a navigational structure. I find it useful at least for myself to split things into directories according to their role, group functions that belong together at least in my mind and work only on a small set of files at a time.

That said, there are times when this is impossible, as it is the problem with ECL, which has humongous files with hundreds of functions per-file. In this case there are two issues at stake, one is that C only makes optimal function calls to functions in the same file (maybe that changes with new link time optimizers) and the other one is to avoid exporting symbols.

Actually, file management should be
left up to the system and the programmer should not care about the
storage of their functions. Like in Smalltalk for example. So
instead of dealing with a linear sequence of functions, you can rather
work on a tree or graph of functions, and navigate from one to the
other directly.

Sorry, but I always found Smalltalk's way of working confusing. You just throw everything in a huge, deep, dark bag and everything is at your hand's reach, but that does not mean one gets a really organized project out of it. For me programs are more than just a collection of functions, but that is my personal taste.

That said, I too like to have things gathered up in a somewhat
organized way, so that I may browse and revise the code in a
meaningful way. But there are probably better ways to do it. In
particular when you consider multiple dispatch in CLOS, you could have
several ways to sort out the methods, depending on what you're doing.