This can be done, but you need to be very careful about when and why you do it.

The structure and contents of msdb can change with every service pack, cumulative update or hotfix. Microsoft assumes that it has control over msdb and does not document the changes fixes make to msdb, unless it is particularly relevant to the fix. You need to make certain you restore an msdb with exactly the same fix level as the target server, or future maintenance of the target server may not have the intended results. If you do have a msdb-related problem on a server that has an out-of-step msdb, Microsoft may ask you to reproduce the problem on a correctly configured server before they give you further assistance.

If you want to install a standard set of jobs on to a new server, then restoring msdb is the wrong way to do this. You should generate scripts for all of your jobs, then run these scripts on your new server. The same applies for any other type of data initialisation.

If you want to restore msdb as part of a DR process, then this can (just about) be justified.