Advantages of the command line over GUI applications include:

1. If you are writing such tools rather than using them, the command line is easy to develop for. Accepting arguments on the command line is trivial and outputing to a text stream is similarly easy.
2. Command line applications can easily be used in batch files or scripts, which is great for automated testing or builds. Most build tools, like make, ant and msbuild provide good support for calling command line tools.
3. The input, output and error streams can easily be redirected, allowing information to be sent or received from files or other applications. This can mean test data can be easily supplied or output captured.
4. There is a simple but standard error return mechanism (return code and the error stream). Detecting an error in a GUI may require UI automation.
5. Use over remote shell or similar connections makes it much easier to perform tasks remotely, such as when a developer is connecting from home or on the road. Remote desktop connections are more prevalent these days but require more bandwidth and a lower latency connection.
6. There are defined standards for help (such as the unix man command or passing -? as an argument). If someone does not know a feature, they can easily see what the tool provides. Similarly, there are defined wildcard syntax standards for specifying multiple files, drawing on likely existing developer knowledge.

However, command line applications have these disadvantages compared to GUI applications:

1. Command line applications are harder to learn to use, particularly for those not used to them. This is usually not a problem for software development because developers are often used to command line tools but could be problematic for less technical people involved in development such as junior QA, localization and technical writers.
2. Command line applications require a keyboard and so are impractical for some devices like phones or tablets.

I assume you mean using a command-line compiler instead of an IDE. Leave a comment if not and I’ll delete my answer.

Learning. Learning how units of code are compiled, linked, or mapped together in your language. Typically you must explicitly tell the compiler which files to compile and link. So you gain a better understanding how it works. An IDE will do magic to make your life easier but will keep you ignorant.

You then take it a step further and learn to create your own make-file. This is a valuable skill. Your make-file makes the build cycle approach the convenience of “IDE magic” while still retaining full understanding and learning.

In addition your build process is easy to put in source control. And it’s easy to port your build process to work with a variety of compilers. Sometimes it’s just a matter of changing 1 line in the make-file for the compiler name.

You develop skills that allow you to work many platforms. Text editors and command line compilers are very similar from all vendors and on all platforms. These basic tools give you a pass to develop on any system, any time, any where 24/7. If you’ve been living in Visual Studio all your life, it’s going to be a much harder transition to work outside of it.

If you go down this path you may want to bother to learn an advanced text editor like VIM. It complements the ability to work on any platform since it’s supported almost everywhere. It has a huge learning curve but the pay off is the ability to edit text effortlessly at high speed without moving your hands to the mouse.

BTW, I am not against IDEs.

GUIs have the advantage of being able to use advanced visualisations. This can be extremely useful to make complex data meaningful.

Command lines, on the other hand, are often more powerful (e.g. fully scriptable) and also usually faster. The other answers have expanded on that – here I’d just like to mention that GUIs don’t offer an advantage for some tasks:

In development, many tasks don’t actually need any visualisation that cannot be done using a command line / text interface. Take compiling: good text editors (Vim, Emacs) readily support error message parsing and will jump directly to the error in the code. Graphical IDEs don’t offer more. Simply put, for such tasks there is no need for a graphical interface, and you’d lose the flexibility and efficiency of a command line interface.

On the other hand, an interactive visualisation can be very useful if you’re dealing with a complex data interaction. Version control software which can display branch graphs often beat text interfaces here. For instance, this is a snapshot from one of my repositories:

This is much more convenient than the text interface, even though this isn’t even a particularly powerful visualisation. But once again, note that actually manipulating the repository is faster using the command line (at least for me). I use the GUI just to display the branches.

Also note how Github has recently added a command line interface in recognition of the fact that many tasks can be accomplished faster by typing in a command than by clicking through a web page.