You answered your own question: ". . . they plan, monitor, delegate, analyse risks, costs, time etc."
According to PMBOK, the PM is also in charge of killing the project when it is non-viable (reality often falls short of that goal).
Since you answered your own question, I have to infer that you don't understand the value such activities bring.
The entire project is a risk taken by someone (the sponsor) who has put up money and resources and expects software in return. That person (the sponsor) has a right to know:
* When the software will be delivered? What is the schedule? If Coders were bots who delivered a fixed number of error free lines of code every day, this would be simple. In reality, code is uneven; some is trivial, some is challenging. The original estimate is just an estimate. The PM should be constantly revising the delivery date/schedule so that the sponsor knows what is coming. This is a continuous cycle of planning, monitoring, and replanning so that the PM can always tell the sponsor when the project will be done (usually as a confidence interval, "there is an 80% chance we'll be done by July 20th, and a 99% chance we'll be done by August 15th".
What will it cost? This is less common on software development, but I've recently hit a situation where we're going to have to spend an extra million because a purchase didn't go through on time. (and that doesn't count the time that the team will spend idle waiting for the software to come in). Cost management matters to the sponsor, but it also matters to the team. Apart from the obvious (if the sponsor doesn't like your cost management, he or she can just fire the team and invest elsewhere), cost management can affect whether you've got useful work to do; because I failed to track the purchase, the team will sit idle for several months, unable to work on the project. My failure will affect their quality of work.
Risks - Done properly risk management is a huge service to both the team and management. A friend of mine in a software development project recently ran into a problem that the development environment was generating different results than the production environment with the same code. That problem had to be located and resolved or the whole project could have been dissolved. The PM should be applying risk/issue management to scope out the implications and generating a variety of scenarios. Do we scrap one of the environments and rebuild? Do we pull in an external audit team and try to find the difference? Do we just hang on and pray that someone on the development team will find the solution? Risk management should also include "The code you just wrote on package X could probably also address the requirement on Project Y; do you mind if their lead tech comes over and takes a look? If it works, you'll be responsible for accelerating their schedule by 3 weeks, and you'll gain a lot of reputation." That's opportunity management.
You didn't mention it, but probably the most important job of the PM is to manage scope - to ensure that the customer doesn't enlarge your task to the point where it is no longer possible. To make sure that small change requests don't add up to a huge, unsolveable problem.
The PM's primary task is to prevent you from being asked to draw seven perpendicular red lines
Having said all that, I think the most important answer is the one given by @Tobias, "The PM enables the team to work without disturbance." Tobias' answer is really quite excellent.