It seems like writing tests is extra work, gives people a crutch when they write the real code, and might not be effective very often.
Unit testing has value as a crutch. It supports your development efforts, allowing you to change your implementation without fearing that your application will cease to work as required. Unit tests are also much more than a crutch, as they give you a tool with which you can validate that your implementation matches the requirements.
All testing, whether unit tests, acceptance tests, integration tests, and so on, is only as effective as the people using them. If you approach your work sloppily, your tests will be sloppy, and your implementation will have problems. So why bother? You bother testing because you need to prove to yourself and your customers that your software works, and hasn't any problems that could prevent the software from being used. Yes, tests are definitely extra work, but how you go about testing will determine how much effort you will need to put in fixing bugs after release, and how much effort your code will require to change and maintain.
I understand how unit tests work and how to write them, but can anyone make the case that it's really a good idea and worth the effort and time?
TDD, and really any method that requires you to write tests before you code takes the approach that you put in an effort early as a down payment on future technical debt. As you work through the project, anything that gets missed, or is not implemented well will incur more technical debt in the form of increased difficulty of maintenance, which directly affects future costs and resourcing requirements. Testing up front ensures that not only have you made an effort to address future technical debt, but also ensures that you encode your requirements in such a way that they can be verified simply by running your code. Test first also gives you the opportunity to validate your understanding of the problem domain before you commit to solving the problem in code, and it validates your implementation efforts.
It really comes down to attempting to maximize the business value of your code. Code that is largely untested and difficult to maintain is generally cheap and fast to create, and very costly to maintain over the lifetime of the product after release. Code that has been tested thoroughly at the unit level is generally more expensive to create, but costs comparatively little to maintain over the lifetime of the product after release.
Also, is there anything that makes TDD especially good for SCRUM?
TDD is not specifically good for any particular methodology. It is simply a tool. A practice that you can integrate into your development processes in order to help you to achieve your specific outcomes. So to answer your question, TDD is complimentary to your method, whether it is SCRUM, or any other approach.