I think you should certainly write as many tests for the application as possible. They will help you learn the codebase and prepare you for the eventual refactoring or new development.
There are a few kinds of tests you can write in that scenario, each of them has their own merits. Writing these tests will teach you a great deal about the application you're dealing with.
First of all, before you set off writing tests for correctness, write tests that capture current behaviour, be it right or wrong. It's a pretty safe bet that you're going to uncover bugs in corner cases or in parts of the code that weren't thoroughly tested by running the program. Don't worry about what the code should do, just capture what it does. As you proceed, don't worry about reading the code or spending serious time figuring out what the output should be. Just run your test and capture that output in an assert.
That will give you a solid base of understanding of how the code operates and where the major pain points or weak areas may be. If you do uncover bugs, you can then approach people with the power to decide whether they're worth fixing or not and make those decisions.
Next, you can write a few bigger (in scope) tests that cover parts of the code that may not be easily unit-testable but where it would still be important to test workflows as much as possible. These workflow tests or integration tests, depending on how you want to look at them, will give you a good base for refactoring those workflows to make them more testable and protect you when a new feature needs to be added that might affect an existing workflow.
Over time, you will build up a suite of tests that is there to help you or the next person who ends up inheriting the application.