With the ability to create Many to Many (MtoM as I will reference them in this post) in CRM 4.0 people are so excited to use it they sometimes use it just to use it, even when it's not necessary or it's the wrong type of MtoM. Let me clarify.
Out of the box MtoM relationship just link one record to another. Nothing more. There is no additional data that gets tracked, only a link. This type of relationship is fantastic for things like seeing Associations that a Contact is affiliated with. You don't need to know when the affiliation started or anything else, just that the Contact is affiliated with that Association. NOTE: Association would be a custom object in a given CRM system.
However, the moment someone says that data needs to be tracked in that relationship you should NOT use the out of the box MtoM relationship. For example, Seminars, Events or Tradeshows are a great example of this. A Seminar (custom object) would contain data about the date and location of the event. However, the most important thing to track from a Seminar is who attended. This typically links to the Contact object. With the out of the box relationship you won't know if the person actually attended or not. If you enter the attendees after the fact, then sure that would work. But most of the implementations that I've done want to track who has registered and who actually attended. This way they can see how effective their registration process is and how effective they are at winning a deal when someone actually attends. This scenario requires what is typically referred to as a "linker" table. Seminar links to Seminar Attendee, which links to Contact. The Seminar Attendee is the link to both and it has a look up to both Seminar and Contact. It's actually a Mto1 relationship with a 1toM...if that makes any sense to anyone else. A Seminar will have many attendees, but a given attendee can only attend one seminar. An attendee can only be one person (Contact) but a Contact can attend multiple events.
Both options are great solutions to any given situation just be wary to use something new just because it's there. Just because the other method is older doesn't mean it's not as functional. The capabilities are there, let's just make sure our users get the systems setup correctly.
Good luck out there,
Dynamic Methods Inc.