I'm not sure what I can say, it depends mostly on your company policy.
There are not a lot of situations where covering 100% of paths with tests is a desirable goal, even when money is involved (note that 100% of lines != 100% of paths).
In the end, it's about balancing the cost of writing the tests vs the cost of not writing the tests. The cost of writing the test is more obvious: your time, and extra time to run the test suite. But not writing it is harder:
You can't determine this exactly for individual tests of course, but the company should balance these factors and aim for a reasonable amount of test "coverage" (not a % of lines but a somewhat subjective fraction of reasonable cases).
I'd also suggest comparing to the coverage of other, equally critical code (in your company). If similar code is better tested, you should catch up. If other critical code is hardly tested at all, you'd be better of writing tests for that than adding edge cases for your code.
I'd add that I would personally love to write perfect code with near-100% coverage. If someone more important than me tells me to do it, I'll be happy to comply, despite doubts about profitability. Usually though, they tell me to do less of it because of time constraints.