I don't buy your reason in this case. There are other situations where the user can't deliver (e.g. with the precondition) and they don't even see that in advance. Wanting to be able to limit who can deliver to a component by ownership is from my perspective as legitimate as the other precautions we already have. To me this is a gap and I think if RTC is supposed to be used in big enterprises it has to adopt to these kinds of things.

It would even be possible to use the pessimistic locking mechanism to prevent a user from accidentally making changes in this case.

There is a good argument for a user should be able to do what they want. But there is also a good reason for being able to protect stuff in some cases.

Anyway, this is certainly not the platform to discuss this as there is too few space in comments.

I don't, by the way argue that users should be able to do their local changes and be able to e.g. check in to their repository workspace. What sometimes should be prevented is delivering to the component. One example: certified code stored in the component and you want to make sure only that is available to users etc.

A few comments on the points raised by Ralph:
- The fact that we have a bunch of other permissions does not imply we should have this permission.  
- The fact that we have added new permissions over time does not imply that we should add this permission.   My argument has never been that it is hard to do (it actually isn't hard to do) ... my argument has only been that it would be wrong to do.
- We are talking about write access, not read access control.   I completely agree that you need to provide read access control to the component as a whole, and this is supported in the product today.   The fact that you have read access control at a certain level does not imply it is desirable to have write access control at that level.
- The fact that someone can write changes to their own stream of a component in no way implies that this somehow gives you greater access to any other stream.   If someone says you cannot deliver to their stream, you cannot.   It doesn't matter if you happen to have some change sets in that component.   That's like saying "I have to remove write repository to the entire repository to ensure you cannot make changes to a component".   That is of course not true, and the same applies here.
- In the presence of distributed delivery, a "global write lock" makes no sense.  As soon as you replicate that component to another repository, you lose the ability to prevent someone making changes to their replica of that component.   How is that significantly different from allowing them to make changes to their stream of that component?
- Pessimistic locking is also stream based ... it prevents someone from making changes in the context of some particular stream (just like the other write access control mechanisms).

WRT your last point:
 "I don't, by the way argue that users should be able to do their local changes and be able to e.g. check in to their repository workspace. What sometimes should be prevented is delivering to the component."  
There is no such thing as "delivering to a component".   Do you mean "adding a change set to the component"?   As soon as you checkin an file, that change set is added to the component containing that artifact.   So you cannot allow "checking in" but not allow "adding a change set to a component".
- And as a reminder: the fact that someone (or even several people) wants to do something doesn't mean it is the right thing to do (:-).