I haven't understood the need for Bower either. If I want say jQuery or Angular I just go to their websites and copy the CDN url. I don't see the problem to be honest.
The need for something like Bower or Browserify comes when you have complicated projects with lots of dependencies, some more than one level deep.
For example, app A depends on library B which depends on library C. If C is jQuery and those are all the dependencies you have, it's fine; but when a project grows a little larger, you do want a proper system.
This is not an uncommon thing; modularizing an app or library into many small, independent parts is simply good practice.
Concrete example: Our company has a library which is currently monolithic and too big for its own repo, so it needs to be broken up into many different modules.
For this we have to have a dependency system because every module in the library needs to be able to say that it needs another module to run.
Plus, if you are developing an app that uses (a bunch of modules from) the library, you want to be able to work on the module code concurrently. Having to minify/package library code and copy it into the app every time you make a change is very inconvenient.
Plus, eventually you need to bundle a single file, eg. mylib.min.js, that combine all the modules. Also a chore without a dependency system. Might be fine for just isolated one case, gets stupidly annoying for the next project, and the next, and so on.
What I like about Browserify is that you just require libraries in your code where you need them, and that way all dependencies are expressed in code; whereas Bower has explicit metadata, separate from the code, which may get out of sync over time.
Well, I can see it being useful if you're already on the command line or if you have to set up a lot of different projects with different configurations.
