While refactoring other people's code might sometimes be necessary, I think refactoring a team-mate's code is just wrong.
Actually, having to look at some team-mate's code is a team smell.
That code is none of your concern. You are to use the interfaces provided and expect the implementations to work as agreed upon. The implementations are not yours to maintain, the interfaces are not yours alone to (re)design, because they are to be a team concensus.
Code refactoring is the process of
changing a computer program's source
code without modifying its external
functional behavior in order to
improve some of the nonfunctional
attributes of the software.
Refactoring somebody elses code will not yield any measurable improvement on your side of the interface.
If you realize, that the implementation someone else is responsible for constitutes a performance bottleneck or a source of errors, then this is something completely different. This is external functional behaviour, that does affect your work and the project as a whole.
In that case, coming forward with fixes is not wrong per se, however you should try not to upset team-mates, to hinder them in their professional development (people grow from problems) or to add so much code, that you also need to take responsibility for the module in question.
I myself have experience with people who use refactoring other people's code as a way of procrastinating their own work. And I've often been witness to "optimizations" that simply add a number of assumptions to the implementations, making it fail in almost any corner case considered in the original version.
Now it's not that I don't like procrastinating with refactoring my own stuff or to dysoptimize my own code. What would programming be without shooting myself in the foot every now and then? But I am allergic to other people shooting me in the foot.
If desired, shared code ownership can be well established through pair programming or joint review sessions, but definitely not through sticking your finger in someone else's code.
You don't want spaghetti code. Why would you want a spaghetti team?
Separation of concerns is an extremely powerful concept, when trying to get complex systems to work smoothly. A team is also a complex system.