It's interesting that you refer to needing "the role of an architect". I would say that you'll always have architecture. What's important is whether it's the right architecture; that suggests the role of an architect. There is no implication that this need be an individual, a former team lead or outside the team - that is often imposed by corporate structure.

There are efficiencies with having the architect as the implementor but you also run the risk of the architecture becoming "inbred" and unimaginative. You continue to play to your strengths, or worse, your mistakes that noone picked up on. Your example of the implementor picking up on duplication seems unlikely - I can see this sort of situation having been farmed out to three separate development teams. Only someone outside the development teams would have picked it up! If you've got a bad architect then of course this might happen - but you might just as easily have a bad developer! In any case, I would advise against unilateral action by removing duplication without consultation - it might be in there for good reason.

Developers involved in sales? Sure - the sales effort often requires proof of concept and prototype work to be undertaken. Developers as salespeople? Not so sure - it's a different skillset altogether. That doesn't mean that there aren't developers with those skills but I notice you didn't suggest that salespeople become developers during the good times - is the relationship between their skills really asymmetrical? ;)

Finally, do people choose to become architects because they can't (or don't want to) code? In truth, I suspect some do. Beware the "Architects Don't Code" anti-pattern! I can't imagine how an architect will produce (or review) a production-quality spike architecture if they don't code well!