With most projects I've worked with, critical development pieces are source-controlled, ensuring that they can be deployed and replicated in any environment. These would include core templates, solution items, etc. that are not expected to be changed by authors.
However, it seems like there is a problem in the workflow if content being built by authors needs to be published between different content management areas. It would be worth digging into why these items have to come 'down' and why they need to go 'up' between environments. There are many reasons why a 'single source of truth' is not possible, but until you start peeling back they "why" layers it will be hard to solve.
Some common scenarios I know of where this type of workflow starts out:
1. Developers are building pages, not just solution items, that will be part of final production usage. These need to flow upwards through Dev->UAT->PROD as part of delivery cycle.
2. Developers and testers need to check production content against new upgrades/features before launching to production. This tends to require a flow downwards from PROD -> DEV (or PROD -> UAT)
3. New templates or components have been built that are not in production, so the new pages that require these components need to be built in a lower-environment (where the component is) and migrated up. Sometimes this looks like UAT->PROD as authors work with the new functionality, try it out, and find issues. They tend not to want to rebuild the page again in production after the deploy, so they need to push their items.
These are all valid workflows, but using publishing to solve it leads to problems (as you found out).
You are absolutely correct Lauren, this sounds like a very valid problem scenario with a problematic solution.