A patchy test suite is a common occurrence on projects. The application is often only as good as its weakest area (though it may be weak in an area that is seldom used). The weakest area is likely to be worst tested.
Rather than writing automated tests like crazy when it’s easy, and dropping back to writing none when it’s hard, aim for even coverage throughout. It’s a good idea to create an informal policy for what things should have automated tests as a a matter of course, and what things are considered trivial enough not to require tests.
On a related note, if some parts of the system are hard to test, it’s almost always because of dependencies that are hard to break. Don’t wait around hoping the problem will get better because it won’t. It will actually get worse faster than average. Those same dependency problems will tend to suck in any new code that touches the “untestable” code. What could otherwise have been easily testable can become untestable unless you make an effort to solve those dependencies and get code under test as early as possible.