I've found ANY documentation is better than NO documentation. The appropriate amount is usually determined by the amount of time we have to do it, or by how much we hate support phone calls and emails.
It appears that your current team members have some unrealistic expectations of their memories, or they are ashamed of their writing skills, and are unwilling to practice.
I realize I am in a minority (English major who got into software engineering in graduate school) here, as I don't find documentation as a chore. It's a valuable professional tool. I may not find writing as difficult to do as some of my coworkers, but that's mostly because I have more practice at it. I don't consider a project finished unless it has documentation, and I usually write it for purely selfish reasons: so I can give people something to read instead of taking phone calls and emails, or so I can remember what we were talking about last month, or so I can refer to how I did something if I need to support it in the middle of the night.
The best way to approach documentation is to write it AS YOU GO, exactly like writing test code. It's amazing how a few pre-written templates (with headers, stubs of code, etc.) can make documentation easier and faster to do. This way you can capture change as it happens, and you have less ground to cover over time. You are more efficient this way, since you can refer to documentation as you need it, and you change it along the way. Doing so in a wiki, for example, makes updates easier, and you can avoid document version issues if the latest and greatest is always online in the same place, and you can just send links to people who need to read it.
If you spend a little time documenting, you will ALL work faster, especially when someone new joins the team, since they won't have to spend all that time figuring everything out. Figuring stuff out is a fun part of our jobs, but it's not fun when you have to do so in a hurry to fix production. We'd all save a lot of time if we all wrote a couple more notes.
Does your team have the same issues with testing, or writing test code? If not, this will be an easier sell.
Your documentation is useful in many ways:
1) To you, right now, and to your coworkers, as you work on the project.
2) To your customers. Having documentation (including diagrams) that you can show users makes discussions in meetings easier, especially if you are discussing complicated systems. Even if the documentation is incomplete, it's a place to start from.
3) To the people who will inherit your work (which may even be you, in three years). Many of my younger co-workers think they'll remember stuff forever. I know I won't remember it past this week if I don't write it down. Having documentation saves you from having to spend half a day to remember how you structured something, and having to figure it all out again.
4) To you and others, if the situation gets political or contentious. As someone who takes notes in meetings, to keep myself awake and fight boredom, I have often been the only one with the written version of a decision. The person who wrote it down wins the dispute. Remember this the next time someone says "Remember that meeting we had this past winter in conference room 4, when we were going over X? Fred was there, and who's that guy from Accounting?"
