You're confused.  `rmdir` simply doesn't care about link counts.  The logic is quite straightforward.

Once a file has a _link count_ of 0, and additionally, no running processes with a reference (file descriptor or current directory), it will be truly deleted.  That's the point when the disk space can be re-used for something else [*].

Directories are a file.  But unlinking (removing them from their parent) requires more consideration than other types of file.  We must make sure each child of the directory is unlinked as well.  Otherwise, we could lose the chance to update the children's link count.  We would lose that disk space permanently.

So we don't let users call `unlink` on a directory.  Instead, they must use the special-purpose `rmdir`.  Calling `rmdir` differs from `unlink` in just two ways

1. It requires that the directory is "empty", which means that its only children are the standard `.` and `..` entries.
2. It makes sure to unlink these two remaining entries, before it runs `unlink` on the directory itself.

That's _it_.  There is no other magic.  `rmdir` is not deferred until the condition in point 1 holds.  `rmdir` either succeeds or fails at the time it is called.  Nor is the condition based on link count in any way.

---

I find the effect of the `.` entry on link counts interesting, even though it's not a special case.  It's a hard-link to the parent directory, and therefore increases it's link count.  This is the explanation for why a newly created directory DIR has a link count of 2.  If you then call `rmdir DIR`, the link count falls back to 0, because it removes both links `DIR/.` and `DIR`.

---

Linux actually allows you to observe the above by running a shell inside the directory, and running `ls -ld` after the directory has been unlinked (removed from its parent).

Of course `ls -ld` is shorthand for `ls -ld .`.  `.` and `..` keep working even after the directory entry is removed; in fact modern Linux does not really rely on these on-disk directory entries.  I expect the original Unix implementation would _not_ support this.  However I believe the reference counts still worked as described above, and did not have a special-case for the removal of a directory.

(How `..` continues to work is even more interesting.  Discussed in comment below).

In fact it would be very easy for you to look at the original Unix code for `rmdir`.  It was [implemented as a user program running with special privileges](https://groups.google.com/forum/#!topic/comp.os.minix/paKhZZWixEE).  Historical unix code is easy to find online.  It's one reason I'm so confident about this.

---

[*] So you can see whether a file has been deleted by looking for a difference in used disk blocks in `df .` (or i-nodes in `df -i .`).  This approach works nicely in filesystems like Linux `ext4`.  Less traditional filesystems may have more complex optimizations though, which can make it harder to observe.