Note that, by definition, this is going to be opinion based. However, this seems to be a cry for help, or assurance, or something similar, and I don't want to not respond to that.
Short version: it depends on the company, and the industry. There do seem to be some companies that seem fine with letting their clients do all the testing. Some companies prioritize release velocity above all else, and QA "gets in the way." Often, this will continue until things go horribly, horribly wrong, or their clients won't let them get away with shoddy products anymore (often when they have competition), or when they get regulated.
To try to answer your questions:
1) They can be. At some level, developers have to come first; you can have developers without QA people; you can't have QA people without developers. So there's often a perception that developers can do their own QA. And sometimes, they can, depending on the product/usage model/etc. However, they often can't do it very well, for a variety of reasons. QA will be seen as important in companies that, for whatever reason, value reliability/user friendliness/etc. Much more importantly, developers will see QA is important in such places as well. If you're in a company where developers and QA folks are seen as enemies, not collaborators, the experience can be difficult.
2) That's a value judgement, and it depends on the type of testing being done. The closer you are to the internals of the product, the more similar the development and test skill set is going to be. If you're doing white box testing, for example, you need to understand how to program. And some types of testing require programming skills as well, to build test frameworks, or automation, or whatever. Other sorts of testing might just require system skills, or data analysis skills, or so on. In my job, in my opinion, a lot of it depends on what scope of the system you're interested in. The developers I work with are incredibly talented, and they understand their area of expertise incredibly well. So individually, they know things like queue theory, and memory allocation, and machine logic, and assembler programming, much better than I do. However, that's almost all they know. They are very deep, but not very wide. I, however, know all of those things, but nowhere near as deeply as they do. So I see a lot more of the system then they do, and I can work with clients a lot better then they can, in general. If a client has a very specific question about dispatching, they would want to talk to a developer, but if they want general information about to how best run their system, they would talk to me.
3) Again, it's very much company/product based. In my area, both developers and testers have a career path that can take them to the same executive levels. There are more developers then there are testers, but testers are seen as having unique insights at a system level that developers almost never have. When we get awards, testers get them along with developers. And our executives/project planners/etc trust us; if we say something isn't ready, it doesn't ship.
In general, QA is almost always going to be at a disadvantage perceptually, because we're the stop sign. The value we add is by making the product better overall, and if we're doing our jobs well, no one notices, because the problems don't make it to the field for someone to complain about.
