Games on top of UDP usually classify messages into "reliable" and "unreliable." "Reliable" messages, when sent, are put into a queue of some sort, and only removed from that queue when the remote end acknowledges the packet that they were put into. If an acknowledge doesn't come in quickly enough, the messages are re-transmitted, until acknowledge is received. This also needs some form of de-duplication on the receiving end (typically implemented using a serial number for reliable messages.)

All the variants you're talking about have been impemented, and work.

The problem with having players hosting matches is that you have to implement NAT punch-through, and only allow players with working punch-through (or port forwarding) to host matches. The benefit is that you don't need to run the game servers yourself.

The benefit of having lobby and game all in one is that the hand-off and management of "who's online" is simple. The draw-back is that there is an upper limit to the number of games you can run at one time, because the server machine may run out of capacity.

The "best practice" for large-scale systems is to run multiple lobbying processes, and also run multiple game processes (perhaps one game per process, if processes are cheap.) When a player logs in, you'd try to assign him/her to a lobby server where other players on the friend list already are. Or you'd assign be geographic location, or something. The point being that you want players to be on lobby servers where they will find friends to play with, and you also want to scale the number of players beyond what a single server can do for lobbying. Xbox Live actually dynamically splits the lobbying -- for most games, it'll be on a single process, but when enough players are online (for the really big games,) it will split; I believe it will split geographically.

As soon as you give a user full administrative rights over the game (being the server), it will get hacked. There's just no two ways around it. Diablo III is went with proprietary dedicated servers for a good reason.

PS: How is this method exacly called that one player hosts game for others? It's not peer to peer I guess and not simply client/server?

It's just client / server. If you want secure games, you will have to host on machines you trust. Either because you own them, or you can validate and authenticate the server content. Usually 'pure' game servers are called dedicated servers. There is no client-side, no rendering or sound, and the game is controlled via a console (entering commands, either locally, or by a games administrator remotely, rcon_password and all that). It's a lot lighter on resources, and you can run several servers on one machine, your bandwidth becoming your bottleneck.

Internet security is a big deal, especially when money is involved (auction houses). Then you run into legal matters. Simply put, a client / server would be the most secure you can hope for, and from where you can build on, and if someone wants to run a moded server and you do not run an authentication service, then there is nothing you can do, apart from accepting it.

If you run a lobby service, then you can run an authentication service. You will need to authenticate users, client and server content, client and server binaries, transactions, communications, ect... SteamWorks, XBox Live or Games For Windows Live are examples of such systems, and as you can tell, it's not an easy thing to do.

if one player is being a server, isn't he allowed to easily hack?[/quote]

Yes.
Many, many games have been quite successful with this model, though. Until just a few years ago, that was the only way that network-hosted games were written.
You still need a server for matching up the hosters with the players, but that's an easier thing to operate.

If you think your game will be popular, and there will be incentive to cheat, then you may need to change to run the servers on your own. The good news, though, is that, because players go to your matchmaking service to find servers, you can make that change later, without breaking anything that already exists.

So, I would recommend this sequence of implementation:
1) Build the game, with manual hosting, and the player having to enter a target address for the game server.
2) Make the game super fun!
3) Build a matchmaker, where hosted games register, and client players can find and join games.
4) Make this matchmaker, and the NAT punch-through, robust!
5) Now if the game is fun and robust, you may start seeing cheaters as a problem. Move servers into your own hosting, and advertise them in the matchmaking as "secure" or "premium" or whatever.

If you complete 1) and 2), you're better off than 99% of all other game projects on the planet :-)