Storing packages in the file system is usually better for development, primarily because you can use source control. (Hopefully your source control archive is part of a regular backup.) You can only store the package itself in a server, but you can store a complete project in a file system. A project might include documentation files, a group of related packages, or anything else that might aide the development effort. In my opinion, package development should always be done with a Visual Studio project stored in a file system.

Is your package intended to execute on a server, or on a client? If it runs on a client the file system version is probably sufficient. If it runs on a server there may be good reasons for deploying the finished package to that server (stored in msdb). In a secure network environment, a remote server may not have access to the file system used by developers, and developers may not have rights to copy files over to the server. Developers can work with the file-based package without affecting the production copy. If a package is used for a critical scheduled job, there are more ways for it to fail if the server has to go over the network to another file system to find the package. It may be easier for the DBA to manage security issues if the package is on the server.