Looking through the comments, I see most people saying these are reasonable standards, so I'll do what I can to give some contrarian two cents.

The standards you list are:
* Code review
* Test coverage
* Meetings over architectural decisions, needs for approval for taking shortcuts

The things you've listed have costs and benefits. The benefits are primarily communication between members of a team, and ability to rely on correctness of code from other members of your team. The costs are time investment. Reviewing code takes time, writing and maintaining useful tests takes time, and meetings for day to day decision making take time. In order for these practices to make sense, the time that they take to implement has to be made up for by the efficiency gained by a team using the practices. To take a trivial example, a solo developer working on code would absolutely be wasting their time to implement all of these things.

These practices also have costs in terms of iteration time on coding decisions. You are much more free to experiment and change around code when you don't have to do these other tasks alongside. This is especially relevant when you are creating a solution to a problem you do not understand well - in that situation initial solutions tend to get thrown away anyway, so there is no point making them to a vigorous standard at extra time cost. Instead, it is better to explore for a solution which works, and then once a good solution is found invest the time in making it robust later.

With that said, you yourself said that you see how slow dev is, and you know how fast it can be with this discipline, which makes it a bit pointless answering your post because you are already basically saying that the way you want to develop code is superior in the post itself. Anyway, supposing that is true, if you prove to the people you work with that you can improve efficiency with the practices you are talking about, and they subsequently ignore that input, then you have definitive prove that the people you are working with are not acting pragmatically.

Fundamentally - when making software the actual task you have to solve is creating software which solves a given task to a given standard of robustness in as short a time as possible. The practices you have listed are strategies for team coordination, and they do not apply to all team sizes. I've read and seen enough of people online who think that every company/team should model themselves on bigger teams - e.g. Facebook/Google/Twitter/whatever, and this leads to a lot of false beliefs in software development. These days people do crazy things all the time because they have in mind some dogmatic notion of "the right way to develop software". In order to be a pragmatic, effective software developer you need to rid yourself of any dogma you may follow, and phrase your questions in terms of what the problems are and how they are being solved. In this case, the question shouldn't be "does my team do x, y or z?", it should be, "is my team utilising its resources to deliver product x to robustness standard y within time frame z?" and if not, you need to know "will practice x help?" and if so how will it help.