Carpenters have this saying: "Measure twice, cut once." Before you cut a piece of wood, you measure it twice, because the cost of remeasuring is much less than the cost of recutting.
The "plan before you act" principle applies to software, too. We make lots of decisions when we create software. We aren't even aware of some of them. The right amount of process can reduce the number of bad decisions. That happens before a QA person tests the software.
In theory, keeping your QA staff involved in all aspects of the software lifecycle allows a QA perspective to catch mistakes early. My experience is that you only get that with a very engaged and knowledgable tester. In practice, getting the tester involved everywhere may be less valuable than the theory suggests.
Correspondingly, giving non-testers input into the test process can improve the test process -- but only if those parties are engaged and knowledgable about testing.
The STLC page you mentioned decomposes the test process into activities, each of which requires different skill sets. That's a idea worth knowing if you are training to be a tester or managing a test team or test process.
You asked how it works in practice. A test process in one organization will look familiar to another organization, but they will vary depending on the personalities involved and the nature of the business. I think most will skip or be informal about some of those activities. For example, most testers at my company do not review each other's test cases.