Short Answer: Absolutely positively.
Long Answer: Unit tests are one of the most important practices I try and influence at my place of work (large bank, fx trading). Yes they are extra work, but it's work that pays back again and again. Automated unit tests not only help you actually execute code you're writing and of course verify your expectations but they also act as a kind of watch dog for future changes that you or someone else might make. Test breakage will result when someone changes the code in undesirable ways. I think the relative value of unit tests declines in correlation with the level of expected change and growth in a code base, but initial verification of what the code does make it worthwhile even where the expected change is low. Unit test value also depends on the cost of defects. If the cost (where cost is loss of time/money/reputation/future effort) of a defect is zero, then the relative value of a test is also zero; however this is almost never the case in a commercial environment.
We generally don't hire people anymore who don't routinely create unit tests as part of their work - it's just something we expect, like turning up every day. I've not seen a pure cost benefit analysis of having unit tests (someone feel free to point me to one), however I can say from experience that in a commercial environment, being able to prove code works in a large important system is worthwhile. It also lets me sleep better at night knowing that the code I've written provably works (to a certain level), and if it changes someone will be alerted to any unexpected side effects by a broken build.
Test driven development, in my mind is not a testing approach. It's actually a design approach/practice with the output being the working system and a set of unit tests. I'm less religious about this practice as it's a skill that is quite difficult to develop and perfect. Personally if I'm building a system and I don't have a clear idea of how it will work I will employ TDD to help me find my way in the dark. However if I'm applying an existing pattern/solution, I typically won't.
In the absence of mathematical proof to you that it makes sense to write unit tests, I encourage you to try it over an extended period and experience the benefits yourself.
Short Answer: Most probably unit tests are not well designed to cover the critical calculation scenarios. In addition, there might be business rule modifications/changes that are not covered in the existing unit tests, because of million reasons that one may face in a tightly scheduled development environment.
As was also mentioned:
Automatic unit testing doesn't imply that the final tests will cover all cases and code will be absolutely correct and bug-free. It is easy not to see some complex use-cases and possible bug.
There might be million reasons why it is NOT done right. My point is that you need to cover these cases with product owner, and then go through each unit test and verify the implementation by applying correct naming of each unit test, as well as by adding the missing once.
If I use the TDD approach, would I disgregard the existing unit tests as they don't show there are any problems with the calculations functionality - and I start by making some failing unit tests which test/prove there are these problems occuring, and then add code to make them pass?
TDD (Test-driven development) will for sure help, but i would NOT discard the current set of unit tests as far as they do what they supposed to be doing.
Best Answer
All TDD requires of you is that you write a failing test, then modify your code to make it pass.
Typically "unit tests" are small and fast and test some part of your code in isolation. Because they are fast, it makes the red/green/refactor loop fast too. However, they suffer from only testing parts in isolation. So you need other tests too (integration, acceptance etc). It is still good practice to follow the same principles: write a failing test, then modify the code to make it work. Just be aware that they are typically slower, so can affect the red/green/refactor cycle time.