In most cases, you won't confine yourself to one of them, instead, you'll use both.
Dynamic analysis means running the software. You don't want to do this with a piece of software that you suspect of being malware, except in a controlled environment.
Also, before running the software, you want to know a bit about it. Is the executable packed in some way? Does it use anti-debugging techniques? Does the software contain any pieces of some well-known / open source library? There are lots of tools out there that answer some of these questions - Ida pro is only one of them.
To further improve your understanding of the software, you want a tool that helps you find dependencies between its parts. Which parts of the binary are actually code, and which are data? If the software contains strings, or other data, that looks interesting, where are those referenced? Which function is called where? This is where the cross-referencing of IDA comes in handy.
On the other hand, in many cases, you don't really need to understand every single instruction of a subroutine to know what it does. You might want to know which files and which registry keys get read and written by your software. Or, you might want to know if it accesses the internet, and which sites it connects to. Running the software with stuff like procmon or wireshark enabled is the fastest way to find out - i'd consider that dynamic analysis as well, even though procmon and wireshark aren't debuggers. Or, while analyzing your software, you come across a function that contains lots of bit operations - this might be some kind of encryption or hashing. Fire up a debugger, set breakpoints on the function, and check its parameters and return values. This can confirm your assumption much faster than trying to understand the function.
Now, you've confirmed the function really decrypts something, and you want to know how it works. You'll probably want to annotate individual opcodes with comments like 'at this point, eax contains all bytes of the input string, xor'red with each other' or 'this doesn't do anything and seems to be nothing but obfuscation'. Tools like IDA allow you to do exactly this.
So the answer is: unless you have a very trivial piece of software, you won't choose one over the other. Analyzing the software consists of many tasks; for some of them, static analysis is easier, for others, dynamic analysis. Any self respecting reverse engineer will have lots of tools at his disposal and pick the right one depending on the task at hand, and quite often, will write his own tool as well to tackle some problems he has with the specific software he's working on right now.
Note that i've never always used the term software instead of malware, as this relates to any kind of reverse engineering, not just malware analysis.
