Not necessary. There is the automatic $kiprjmod variable that always points to the project root.
There are also two usecases. Viewing of kicad files does not really require anything special. Just ensure the cache lib is included. If the person viewing it has different libs setup then they get the rescue dialog where they simply accept the default.
If the other person should be able to make changes then svn or some other centralized version control system might be the better choice. This allows everyone to lock the file they work on and therefore ensures that you do not need to merge stuff.
Regarding libs: you can either use project local libs as this will not require anybody to setup global libs. (make sure the project local lib tables are under version control)
Or use global libs as usual but this requires everyone to setup the shared libs (share the libs either in the same repo or have a library repo separately. When using git then i would suggest using a separate library repo but include it using submodules)
To be honest i would personally prefer the global setup as it reduces the dangers of getting the same asset in a different state for different projects.
As with all things in life there are trade-offs. The centralized system means you have an easier time maintaining your libs but every new collaborator has some initial work to do.
The same also works with dropbox and similar but there i would suggest to go with a project local setup as it is not possible to roll back the lib to an older state when viewing an older version of the project. (Old version would have the older local libs in that case)