Freecad is free. I'm an open source linux bigot. Most of my machines are Linux. I ended up buying Alibre Atom Workbench and tolerate Win10 so I can use it after fighting with Freecad late last year after Fusion changed the rules for hobby folks. I used Fusion as a few years ago I tried Freecad and it didn't work out so well and Fusion360 did. I'm not interested in getting involved in the software development of Freecad, and I'm not going off on the Freecad folks. It's unlikely that I could do much to sort out the issues with Freecad as I'm not knowledgeable enough to provide the expertise that would be required.
Having run large software projects I'll say the following:
1) In terms of consistent user interface and behavior, Freecad is not on par with Blender, Gimp, Darktable, Stellarium, Inkscape, LibreOffice, or Librecad.
2) For software developers to do a good job, there needs to be a clear design based on specific and testable functional requirements. You can write software from a spec without being a subject matter expert, but the less you inherently know about how something should work the better the specs have to be. Anyone who has worked on compartmentalized programs knows that you can build a complicated system from pieces made by folks who only know their small part of the puzzle.
2a) Standardized workflow / terminology guidelines would reduce many of the inconsistencies in the different workbenches.
3) Most, but not all. open source projects of large scale that are widely used and well regarded have some level of user, institutional, government, and/or corporate sponsorship. I don't know what level of support Freecad receives, or how the funds received are controlled/applied to the project. That is not a criticism or a questioning of the folks involved with freecad regarding funding. It is a consideration as finding and hiring people who are both subject matter experts and good tech leads / specification developers isn't easy or cheap. I would hate to have to run a volunteer project for more than a day or two. It's hard to tell a volunteer "No. We will do it this way. I know you love the idea of flashing inverse purple text for help messages, but oh hell no!" . As a volunteer, hearing such a statement makes you wonder why you are giving so much of your time.
4) Developers can only test their own code to a certain extent. With complete integrity, no ego issues, and willingness to find faults, the developer will find many things as they work with their code. They will not however find the things they just plain got wrong conceptually, or most design defects, particularly if the design specs are incomplete or faulty.
5) Good testing requires good test plan(s). You can't always have a specific and quantifiable test case, but that should always be the goal. The test case items should track the design spec items. The design specs should track the requirements. Helps avoid the question "Why would you do that?" being answered with "It seemed like a reasonable next step. If it's so bad why did the app let me do it?". This loops back to item 2.
6) Software methodologies/languages/operating systems come and go, but the underlying rules don't change.
My last app role out for a specialized sort of requirement went to about 28000 sites simultaneously. It was back in the day of CD distribution and installation, not just a case of authorizing 28K users for a web app. The help desk folks still got to go home at the end of the day and get lunch. We still got along two weeks later. Just mentioning this to show that I have at least some experience to support the above thoughts. Over the years I was on teams called on to sort out programs in trouble (software and hardware) quite a few times. Funny thing is the root causes were almost always the same. Vague or missing / incomplete understanding of how the thing was supposed to work that didn't get resolved before getting way down the road.