It's easy to write tests that have no value. Especially if your employer mandates them. "You wanted tests. Here's your tests." If that's your criteria for tests then you're exactly right. The only thing they're doing is appeasing your clueless employer.
Writing actually useful tests is a hard won skill. It is not something that emerges easily when writing tests just because you were told to. You need to have a use for them in mind and do work that proves if they actually do prove to be useful.
It doesn't help that there are different philosophies about how it should be done. Some want every class isolated and all it's dependencies mocked. Others want only high level tests that prove some behavior exists in support of some requirement.
I come to the conclusion that, much like documentation, the most important thing to consider is a tests audience. A test can do a lot of damage if it was meant to prove a functions behavior that turns out to be replaceable with a completely different function with a different behavior that can't pass this old test. Such tests are fine in the hands of those that can see that and know to discard the test. But when others get hold of that test and wont let it go, it makes refactoring harder, not easier.
There are tests meant to satisfy your product owner. Tests meant to satisfy QA. Tests meant to teach new coders how the API works. Tests that enable refactoring without changing behavior. Tests meant to prove this implementation happens to behave the way you think that should never be shown to another coder.
Many argue about what to call these tests. Unit tests, integration tests, acceptance tests, end-to-end tests, automated tests, regression tests. These terms have become meaningless to me because I've seen them used to mean so many different things. I've learned to just keep asking until what the term means in this particular shop is made clear. What I want to know is what the point of the test is. I just don't trust the names to tell me that anymore. Burned too many times.
You're stuck with a testing requirement and no clear vision of what the point of that requirement is. I've been there. It's tough. If you have the time, try to identify the most useful thing you could do with testing for your employer. Put your focus there before trying to master everything.
TDD is an art. You really need to practice at home. TDD done halfway makes a nightmarish mess. You'll know when you have a handle on TDD when you do it, not because you're supposed to, but because it makes you faster. If it's slowing you down you're still not ready to do it at work.
Testing for planned refactoring is another story. Michael Feathers book Working Effectively with Legacy Code is a must read if you want to transform a code base with no tests into something else that has some tests that prove that you only changed what you meant to.
Shops where the point of tests is to have tests, not to use tests abound. Figure out something truly useful to do with them or your shop will turn into yet another one. If it does they will slow you down and cripple you.
Probably the best thing you could do is make the point of each test clear enough that those who come after you will have no doubt when it's time to delete the test. This is critical because when in doubt coders tend to drag old useless tests around.
So when you ask, what's the point of unit tests, my answer is nothing until proven otherwise. If you can't figure it out then it needs to die. Clutter is not helpful.