Web designers use vendor prefixes in their CSS stylesheets to improve browser support. Many properties can be currently written with their prefixed versions, even if they aren't strictly needed. This can confuse people or make them write inefficient code. Lea Verou's tool "prefix-free" can alleviate this problem, allowing to write simple code that will be transparently converted to contain the prefixes needed by the browser. It can speed up the web development, but it won't change the fact that browsers still need to load these additional properties behind the scenes. As web designers, we will be happier, but our users will still have to wait longer. We should never sacrifice the outcome for the user (even if we might work with a client) in favor of our own convenience. If we aren't improving the actual value we deliver, we are doing something wrong.
Sharing code snippets of working demos requires that all vendor prefixes are already applied, and that will further contribute to their spreading around the web, even if our goal is to create cleaner stylesheets overall. Then it can become a maintenance problem if we can't easily distinguish which prefixes come from "prefix-free" and which from simple copy-paste (another reason to avoid it).
Vendor prefixes have the nature of duplicate code—we just describe the same value with a different property. In any programming language, code duplication is considered a bad practice that should be avoided. It can slow us down, because we need more time to read and maintain the code. Forgetting to apply the same change in another place means that we are more likely to introduce unintended bugs. Databases also shouldn't contain duplicate records, since this would be a waste of disk space and will slow down query execution. A bigger result set will need more cycles to be presented to the user, potentially slowing down our application. But we still continue to tolerate duplication in stylesheets—in the form of vendor prefixes—and try to be on every browser, platform and device. This has a cost that our end users will need to pay. It would be too simple to suggest avoiding prefixes at all, since every project will be different. But at least we can minimize their use and apply them as rarely as we apply hacks, and not for every property-value pair. If we start to actively discourage vendor prefix use today, we might help the people who will maintain our sites in the future.