Could someone explain the pros of deleting (or keeping) unused code?

Code is already written, and efforts are spent

It is also unnecessary. If you do not use it for anything, it is (by definition) useless, regardless what it does or how much effort was spent on it.

Code may be tested on syntetical and real environment

If it's useless, it is still useless even if you have tests on it. If the code is useless, the tests for it should useless as well (so keeping the commented code there, creates ambiguity - do you keep the tests? if you had client code of the commented code, do you comment the client code as well?)

If organized well (grouped, separate package, loosely coupled etc) it doesn't disturbs you on overall code analysis or refactoring

Not so. All your tools (source control, static analysis, documentation extractor, compiler, etc) will run slower, because they have to process more data (and a bigger or smaller part of that data is noise).

If the code is not organized well on the other hand, it will mess up static analysis, refactoring, and any others.

You're introducing noise to your tools input and hoping they cope correctly with it.

What if your static analysis tool computes a comments/code ratio? You just messed it up, with something that was relevant up until yesterday (or whenever the code was commented).

Most relevant of all, commented blocks of code introduce delays in understanding the code for maintenance and further development and such delays almost always cost a lot. Ask yourself this: If you need to understand the implementation of a function, what would you rather have to look at? two lines of clear code, or two lines of code and another twenty-six of comments that are no longer actual?

Code may be used in future

If it is, you will find it in your team's SCM of choice.

If you use a competent SCM and rely on it to keep the dead code (instead of cluttering up the source), you should see not only who deleted that code (commit author), but for what reason (commit message), and what other changes were made along with it (the rest of the diffs for that commit).

When deleted, author may feel uncomfortable

So?

You are (I assume) an entire team of developers that gets payed to make the best software you know how to, not "the best software you know how to without hurting the feelings of X".

It's a part of programming, that most code written will ultimately be discarded; for example, Joel Spolsky said at some point that for his company, approximately 2% of written code sees production.

If you prioritize the ego of developers over the quality of the code base, you will sacrifice the quality of your product, for ... what exactly? Preserving the immaturity of your fellow developers? Protecting the unrealistic expectations of your colleagues?

Edit: I have seen one valid reason to leave commented out code in the source, and it is a very specific case: when the code is written in a weird/un-intuitive form and the clean way of re-writing it doesn't work for a really subtle reason. This should also be applied only after a repeated attempt has been made to correct the issue and every time the attempt has re-introduced the same defect. In such a case, you should add the commented intuitive code as a comment, and explain why it doesn't work (so future developers will not attempt the same change again):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Here are some reasons why unused code should be removed:

• For anyone new working on a project, they not only have to understand the working code, they have to understand unused material also. This is wasted time and creates confusion.

• There is a danger that at some time, someone will make a change which inadvertently involve the 'dormant' code and can introduce bugs. I know it's happened on projects I've worked on.

• The maintenance of any code is an administrative burden. By preserving old redundant code that burden is increased. For example, merging changes in the main branch becomes harder because there is more code to work through and more possibility to make a mistake.

• What happens over time is that more and more old unused code is added to the codebase. This increases the confusion, potential misunderstanding and administrative overhead.

• The chances that the unused code will ever be used again is very unlikely. With time that possibility of re-use diminishes. If code is to be removed and is considered important enough then the code can be branched off and documented.

• Any personal feelings that a coder may have about code they may have worked hard on are understandable. But part of being professional requires that those thoughts have to be put to one side for the better good. Time stands for no-one and there is no place for preserving historical code in a working codebase.

Isn't it tough enough to pick up some code and figure out the intent, but now you have to figure out which parts are not in use?

@suspectus has done an excellent job of presenting the reasons for deleting code; I would like to address your individual bullets for keeping code.

• Code is already written, and efforts are spent

But if the already-written code is not in use, this is cost only without (future) value. It is effort invested in vain, and preserving the unused product of those efforts does not validate those efforts. We keep code because it is useful, now, not as some kind of memorial to the efforts of the authors.

• Code may be tested on syntetical and real environment

I'm sorry, I don't know what you mean by this.

• If organized well (grouped, separate package, loosely coupled etc) it doesn't disturbs you on overall code analysis or refactoring

If it exists in the code base, no matter how well organized, it contributes to the maintenance and comprehension burden. True, it can be organized so as to be less of a burden, but if it's gone, it's no burden at all.

• Code may be used in future

In the Agile school, we say YAGNI: You Ain't Gonna Need It. Yes, you might possibly have a use for it in the future, but we can't know enough today about tomorrow's needs to be able to predict that with any kind of reliability. To think otherwise is arrogance tending toward hubris. What we can know about tomorrow is: we want our code base to be easy to modify, and unused code detracts from that characteristic.

• When deleted, author may feel uncomfortable

Author must get over it. We've all written things that turned out not to be useful - far better to be able to point to a body of code that is all being used (because the unused cruft was deleted) than to a body of code wherein you can say of a few methods, "and that one's actually in use!"