1. I've encountered many Software Engineers who believe they are somehow superior to QA engineers. I think it may help quench this belief if they do the job of a QA engineer for some time, and realize that it is a unique and valuable skill-set of its own.
A good software engineering has a background in quality, including testing, metrics, and statistics. Anyone doing any kind of software development should be aware (if not familiar with) maintaining at quality source code and producing/maintaining effective test cases. Over time, I would suspect that any software developer would gain an understanding of the different facets of quality - code quality, portability, maintainability, testability, usability, reliability, efficiency, and security.
Software engineers might focus on a particular aspect of the lifecycle - requirements engineering, architecture and design, construction, testing, and maintenance. However, regardless of your focus (either as a job or at the current phase of the project), it's important to remember quality.
2. The better a Software Engineer is at testing their own programs, the less cost in time their code incurs when making its way through the rest of the software development life-cycle.
That might be true. But some issues are best seen later in development. For example, performance and efficiency issues might not be seen until integration. Having good, solid code and effective unit tests are just the beginning. Quality needs to begin with requirements, and follow all the way through maintenance activities.
3. The more time a Software Engineer spends thinking about how a program can break, the more often they are to consider these cases as they are developing them, thus reducing bugs in the end product.
That's a totally true statement. But then again, it's also up to the requirements engineers to verify that there are no conflicts in requirements, architects to ensure that the design actually addresses the requirements, and so on. Everyone should be trying to poke holes in their work and then working with the appropriate people to seal them up nice and tight.
4. A Software Engineer's definition of "complete" is always interesting...if they have spent time as a QA engineer maybe this definition will more closely match the designer of the software's.
"Complete" can only be measured against requirements. Either the requirements are satisfied and the project is complete, or there are incomplete requirements and the project is not complete. Any other measure of complete is useless.