Good points. I'm not sure I would strive for 100% test coverage though. Lets take the example of tests for all getters and setters. It would take a lot of time to write tests for these, but the return of investment is relatively minimal. Unless there is conversion logic in there, it might be better to spend the time somewhere else.

Another thing about 100% coverage is that it could make the test suite very rigid, making requirements changes very difficult. Complex algorithms definitely should be tested, but 100% of all code might not be necessary.

Another thing to consider is that some code may be very difficult to test, e.g. if using built in third party library objects that do not have interfaces or virtual methods. Depending on the circumstance, it might not be worth bending the code out of shape purely for testability as this may make other parts of the logic either more difficult to follow, or more prone to bugs.