To have some UML diagrams for documentation reasons is definitely a very good point! It would have been helpful in many, many situations to have at least some small UML diagrams to get a brief overview of some complex parts of an application.
Yes. This is one of the greater benefits of using UML diagrams for designing software. It is important to understand that software design and software programming are different processes. UML is a design tool, not a tool for coding or programming.
From your answer I guess you have quite a bit practical experience with this. So just out of curiosity: How do you handle bigger projects with 100+++ classes? Do you break everything down into modules or are some tools good enough to help you manage diagrams of that size? My personal experience is that UML diagrams are most helpful to visualize details of a smaller part or module of an entire application (mostly with class diagrams) but I can hardly imagine to model a really big project with them.
Typically, classes do not exist before the design process. They are a product of the design process. Everything in an application does not have to been diagrammed or designed with UML. In some cases, you might design something, then write the code, and then design a little bit more and add any new stuff to existing diagrams. And, even more radical, maybe some elements don’t exists anywhere in any diagram. The main point here is that the most complex scenarios benefit from the visual design process. It is extremely difficult to design anything complex without some sort of visual abstraction, especially if there are multiple programmers involved. How can the architect efficiently make sure that everyone is working on the same concepts/design?
It is important to highlight that a diagram is just a guide and it might not match exactly with the code. It doesn’t have too. If you want to know exactly what is in the code, then read the code. Diagrams outline the design, not exact implementation details.
Which of all the available types of UML diagrams do make sense for practical use in bigger projects in your opinion?
Sequence diagrams and Class diagrams.
And if you say UML is most helpful for the transition from design to code then how do you handle iterative changes which you obviously will have if you don't use a simple waterfall model as development process?
Software design is an art, not a science. Strong design skills are difficult to acquire and build upon. This is not something that you can easily search "Google" and find the "correct" answer for. A foundation of OO design skills typically takes a couple of years to develop and then requires more time and active engagement to get stronger. If you get it, then you will develop a style that is "best" for you and has worked well in the past for "you" and will be something that you can "teach" to others (in the real world, not via Intenet postings).