The Apple II was the defacto 8-bit machine of choice for most of the North American developers, when looking at the collected anecdotes(Origin, Interplay, SSI and many independents like Jordan Mechner and the team that would form id software were all using them). Becky Heineman had a video where she explained why it was so much better than the C64 and most other options - the I/O and expansion potential was just a lot better on the Apple II architecture, and if you stepped up to the IIGS when that came around you also got some backwards compatibility with more CPU horsepower. Besides displays, the support for multi-disk systems was pretty good, and you could kit out the system to work with a generous amount of RAM and storage for the time. The competing Atari 8-bits also had good expansion capability through the SIO bus and dual cartridge slots which showed some very progressive design, but their potential went mostly neglected by Atari corporate at the time.
The C64 was a budget games machine at heart and didn't have the same kind of hardware support, but its reference manuals are famous for being a great introduction to computing. For many of the beginning bedroom coders this may have made all the difference.
It was way more common to simply not attempt to organize projects in this way "BITD" - it complicates your build system because now it has to manage paths, which entangles it with the OS file system. Not every file system even has subdirectories and not every tool acknowledges or agrees upon how to use them, so depending on how antiquated their dev environment was, it may have been totally impractical.
It's a good question and infects all of our software "sacred cows."
The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things. Thus through repeated application of this approach the world of professional software development has aggregated itself into conformance to standards that barely make sense, are poorly specified, and have limited proof of concept, but tick whatever buzzword boxes are relevant to the immediate climate.
If you want to take a real stand, invest yourself in "dead" technologies. Then you can choose whatever you want, and if other people want to follow you on it it's implicit that they are working on a similar problem, and not trying to play the platforms game(else they would be looking for an angle to "modernize")
The C64 was a budget games machine at heart and didn't have the same kind of hardware support, but its reference manuals are famous for being a great introduction to computing. For many of the beginning bedroom coders this may have made all the difference.