This topic may sound like something very obvious. The obvious thing is that if you can sell the same code twice you can do more in less time and as such you make more money. This may sound cynical, but if you can do something faster it is a competitive advantage as you can do something in less time for a lower cost for your customers.
It goes beyond that though, having a well-isolated piece of code that is re-used frequently leads to it being tested in ways that you would not necessarily have thought of in the original use-case. Testing that can lead to finding really hard-to-find bugs in the code and fixing them across all usage situations.
At the company where I work we have an SDK that consists of a ton of code that is being used all the time by both us and other users of our SDK. This is code that is being pounded on over and over again by lots of people for hours every day, and as such we can be fairly certain that it is of very high quality.
Another advantage of re-using code is that, with some caveats as to what it is, you can show sort of what it will do even before your new thing is done since you already have something similar. This is incredibly valuable to give people an idea of the final functionality.
There is of course the dreaded downsides of that you may spend far too much time up front building something overly generalized or that you end up spending more time to bend something into something it was not originally meant to do than just building something new.
What this means is that you do have to balance all these things when making this decision. In my mind though, if you've done good separation of your code into re-usable parts, large re-use will be something positive in a lot of situations.
Some re-use can also come in the form of code within libraries etc that is not code written by you. This can be great in a lot of situations as it essentially provides you with the output of extra developers who are usually specialists at the parts that they do.
There is a little bit of a challenge in some situations that you may not be able to see the full internals of something which requires some faith in the quality of the code that you can't see. This is not really a problem though if the code is written by a serious developer who is also likely to provide good support should you need it.
Some developers really get gung up on “not invented here” and don't want to use other people's code, but I think that is quite silly and archaic in a lot of situations seeing how many great developers there are out there producing great code every day.
So, keep all kinds of re-use in mind.