A lot of this is in UserVoice. If not, you should add there as that is where the product teams review and look at votes and such to determine priorities.
The level of control you are looking for is not common (although, not uncommon) in this sort of "be anything to anyone" platform. Quick Base has to balance a cohesive experience that is reliable with customization desires. While you as a builder are their customer, all of your users are indirectly their customer as well. If a builder makes a poor decision and selects clashing colors, weird sizes or any number of other things and users have a bad experience, this reflects poorly on Quick Base. In fact, many end users do not understand what is on the onus of Quick Base vs their organization/builders. You can see evidence of this when the community and/or UserVoice has threads about business-specific issues that Quick Base cannot help with.
Quick Base has a goal of getting builders off the ground quickly. The more choices you introduce, the more choices you have to make which slows down the process and introduces risk. Every single variable, toggle, switch and setting introduced has a virtually endless amount of reprocussions down the line that Quick Base has to account for. Don't forget they don't even know all of the different ways people use the platform.
Many people consider something not being flexible a positive, not a negative. Simplicity keeps risk mitigated. In software, flexible and simple often compete. You can see this tug of war in all industries. Look at the trend with car manufacturers going to an all-inclusive subscription model that includes the car payment, insurance, taxes and maintenance. You lose the choice of insurance company, where you get your oil changed, etc. On the flip side, you don't have to choose any of those things. You write one check and don't have to worry about anything.
The fact that in Quick Base you don't/can't write full HTML to control an entire form for example means you don't have to. It means you can deliver high-impact, lower-cost functionality that adds value quickly for users and solves real problems without dealing with the minutia of indexing a database table, worrying about how fields align on a form or any number of other things that come up in software development. For a higher level of control or if you are trying to whitelabel Quick Base, a flexible API is offered where you could build an entire front end in JavaScript or server-side technology and no one has to ever see Quick Base. By doing this, you take on the onus and responsibility of managing it.
None of the above is meant to be good or bad but rather just discussion points around how this is a little bit more in depth and complicated than it might seem at face value. I actually agree that some of the things you point out would add value to the platform. And while this effort is probably trivial to implement for the Quick Base team of developers, the presentation of the choices, documenting, training and decision making is not. Again, I'm not saying your ideas are bad, shouldn't be implemented or anything like that. I'm just trying to explain that they aren't as simple as they sound.
Lastly, there is no scenario where Quick Base is going to be able to please everyone so they simply have to go with the numbers. People are always most vocal with criticism.
