Now that APFS returns items in unexpected order, recursion (either using a loop or by calling the same method (not recommended)) leads to weird results.
1: when showing the path to the currently iterated folder, the user can no longer “approximately determine” the progress. In alphabetical order, you could think “/Applications” is near the start and “/Users” is near the end, so you could guess the remaining time.
2: in my specific case, I search for files inside a given folder; in order to avoid looking in big folders, since the app cannot predict the number of items in a given folder, my solution is to have a folder “.Do not look here”, manually created in those huge folders. With the disorder made by APFS, I can't assume this will be the first discovered folder, so my app may just list the whole folder before knowing it shouldn't have to, by finally encountering the “.Do not look here” folder. I end up checking the folder's existence using .Child(".Do not look here") but I expect it would be slower (for every iterated folder in which my “.Do not look here” folder isn't existing, I must check for its existence).
I use a loop to list the whole folder (using arrays for folders and indexes). While sorting folders alphabetically would be easy for a single folder (using SortWith and 2 loops), mixing recursion and sorting is harder (I've yet to do that…).
In short: even if listing a folder was never guaranteed to be sorted alphabetically, most file systems do that by default (HFS+, NTFS, FAT32, most Linux variations). Having APFS not doing that results in a step backward in comparison (even if it may have some other useful tricks…).