If a hash algorithm has an option for selecting the output-hash-length (e.g., 128 vs. 512 bits), and all other aspects of the hash function are the same, which hash-length is probably more secure/useful, and why?
How Hashes work
The concept behind hashes is very simple: take a message of arbitrary size, and deterministically produce a random-looking output of a given size. For a well-built cryptographic hash function, the only way to break it is to try random inputs until you get the hash value you want (collision or pre-image, etc).
Which is more secure?
All other thing being equal (ie it's the same algorithm, just with a different output size, ex.: SHA2-224 vs SHA2-512), then the larger the output of the hash, the more secure it is. Reason: if you have a 224-bit hash, then you expect an attacker to have to make 2223 guesses (on average) to break it, whereas a 512-bit has requires the attacker to make 2511 guesses (on average).
Which is more useful?
This one I can't answer for you, it depends on a lot of factors about the application that's using it. For example, whether you have memory, bandwidth, or processing constraints, whether you are able to easily upgrade your infrastructure if the 128-bit hash gets deprecated or if the solution you're setting up needs to be future-proof for 10 years, etc. With only the information you've given, I can't answer this for you.
The first obvious answer is of course "The 512bit hash is better".
A more considerate answer would add to that: "... if the input is long enough". The reason is that while we wish the world and the hashes within that world are perfect, it is generally harder to generate a near-perfect, random-looking distribution in a bigger output given a small input. Thus, a longer hash might have undesirable properties compared to a shorter one if given too short input.
A more practical answer would ask: Are you birthday-bound? If not, forget about the issue, and just use the 128bit hash, which is faster and uses less storage.
If a birthday attack may be an issue for you (signatures?) you will most definitively not want to use a 128bit (or smaller) hash because 264 is a number that is quite feasible as an attack.
Other than that, unless some of the information involved is so immensely valuable that one or several of the largest nations in the world will dedicate the major part of their resources and their presumed super quantum computers for several years to brute force a single one of your hashes (how important are you!?), any non-broken hash is -- in practice -- as good as any other as far as the length goes.
It does not make a difference whether an attacker has to perform 2127 or 2511 or 210000000 steps.
2127 is by all means impractical, and unaffordable (for every realistic scenario), if possible.
One usage of hashes is data signature or checksum.
Assume I provide a file to downlaod for you, and once you downloaded the file you may need to make sure it's not touched(by man-in-middle, bad network, etc.), so here comes the solution.
I provide the checksum/hash of file for you(let say in SHA-512), now you check the checksum/hash of downloaded file and the both hash files must be the same now(but if you assume the hash data provided is no touched too).
You could be surprised that MD5 now is a deprecated hash algorithm. As security legends could hack it in a very awesome way, that you could have two completely different data with the exact one same size and exactly same md5 hash value.
So now I'm not afraid that maybe next year, 10 or 100 next year another legend could do the same thing with the SHAs family.
HMACs are the secure way of hashes. As you need to add more secret data to make the hash. Back in the file download example in above, now you need to make a HMAC-SHA-512 for checking data integrity with some secret value which only you and I know.(the secret val known as salt too).
More security? cannot trust noone in the world? HMAC doesn't work
So the last approach is the your own customized hash algorithm. Yes make it yourself. But obviously you need to do it very well.