From the GPL FAQ (but the advice is applicable to all licenses):
Why does the GPL require including a copy of the GPL with every copy of the program?
Including a copy of the license with the work is vital so that everyone who gets a copy of the program can know what his rights are.
It might be tempting to include a URL that refers to the license, instead of the license itself. But you cannot be sure that the URL will still be valid, five years or ten years from now. Twenty years from now, URLs as we know them today may no longer exist.
The only way to make sure that people who have copies of the program will continue to be able to see the license, despite all the changes that will happen in the network, is to include a copy of the license in the program.
The moment the site hosting you license goes down or changes its URL paths, people who have copies of your software can no longer verify what rights they may safely exercise. Suppose even that you could somehow guarantee that that exact URL will be forever online: the ability for users to verify that their use of your software is legal still depends upon the ability to connect to that particular URL. While this requirement may not onerous in your particular city/country/planet, it may be onerous elsewhere. You should not impose this requirement, especially when the workaround (including the full license text) is trivial.
You might answer this complaint by saying, "So what? If the URL does go down or is not accessible, an unambiguous descriptor like 'GNU GPL v3' should be sufficient. Full-text copies of the GPL are plentiful; users can look up the license themselves." A few problems immediately spring to mind:
This doesn't generalize to license identifiers that are less clear (the phrase "BSD license" comes to mind).
This doesn't generalize well to licenses that are less common or have been customized ("GPL with linking exceptions" comes to mind: which linking exceptions?). How common does a license need to be before it's reasonable to expect a user to find it reliably by name?
This still requires users to have an Internet connection, which may not be the case, even if they had a connection at the time they got the software. (And they may not have had Internet access when they got the software: "the CD age" has not yet ended in many parts of the world. As an additional case, consider national populations that have widespread Internet access but censor large parts of it.) A consequence of freely-redistributable software is that a recipient may not receive a copy of your software directly from you or through a distribution channel you originally anticipated.
One final argument against license links is noted by MichaelT's comment below: it could allow you to dynamically, retroactively change the license. This could be done intentionally, but it could also be done by accident, if you changed the license between versions of the software, but used the same license link for both versions, thereby clobbering your old license out of existence. Such a switch would add difficulty for people who need to prove they got their older copy under a different license than the current version.
So why do I have to keep the license in the project root?
I'm not a lawyer, but I've never seen any compelling argument that you do need to keep licenses in the project root. Even the GPL, which specifies that the license must accompany each copy of the work, is silent on how it must accompany the work. (This may be because the GPL could be applied in non-software contexts, where the notion of "root directory" is not meaningful.)
Keeping the license in the root directory is probably a good idea because it maximizes the likelihood the user will see it, and thereby minimizes both user frustration and the likelihood of complaints against you for trying to hide the license in some obscure directory. If you have many licenses, it might make more sense to place them all in their own folder, and include an obvious project README that contains file paths to find the license for each component.
Placing your license in the directory root is a helpful practice also because it can disambiguate the licenses of modules that are licensed differently that the work as a whole. Suppose my project FooProj uses the stand-alone module BarMod. FooProj might be GPL-licensed, while the standalone module might be MIT-licensed. When I first open FooProj, I see a copy of the GPL in the root and understand that work as a whole is GPL-licensed. When I descend into the folder for BarMod, I see a new license file there, and I understand that the contents of this folder are MIT-licensed. Of course, this is only a helpful aid; you should always indicate the licensing of your modules explicitly in a README, NOTICE, or similar file.
In sum, using the file root is a matter of convenience and clarity. I have not seen any legally binding open-source license text that requires it, nor do I know of any reason why it would be legally required. Your license should be reasonably easy for the recipient to discover; including the license in the project root is sufficient, but not necessary, to satisfy this criterion.