Windows file systems have a "read-only" flag. That is simpler than having to set DACL permissions for such a simple effect.
In a command prompt, use the ATTR command. In the GUI shell it should be in the Properties, though the gui might do something complex and beyond what you really wanted.
Also, if you re-create a directory with the same name you can then apply "restore previous versions" on it.
Update
I experimented on a Win7 system. The GUI delete (without recycle bin) ignores the R flag on the directory. There are no additional prompts warning about it, either, like I've seen for H and/or S flags. Issuing rd from the command line gives access denied as expected. However, you can't just rd a non-empty directory anyway: delete file and remove directory are different commands. A command to recursively remove a directory with contents will remove the contents and than fail to remove the now-empty directory.
So protecting the directory itself doesn't work in the GUI action you have in mind. And it implies that any fancier approach to preventing the directory itself from being removed won't prevent it from being emptied first! You said you still want normal access within the directory to create and remove files, so locking it down completely is not a solution for you.
The best solution seems to be the symbolic link. Making a symbolic link (new style, what Windows Vista and above now call a symbolic link) to the directory on the desktop, when the directory actually exists somewhere else, works in the sense that if I delete the desktop icon (shift-delete, no recycle bin) the actual directory is unaffected as only the link was deleted.
Shift-Delete of the desktop icon did not care if it was marked with the R attribute.
A program using the standard Windows file-open dialog box navigated through the symlink with no problems. It actually resolved the name of the linked directory, so the file opened was the real name; e.g. Desktop\MyFolder became D:\scratch\MyFolder as I navigated through it.
Using an old-style link (a Junction), the program saw the name with the junction still in the path; e.g. C:\Users\john\Desktop\MyFolder\test.txt so the fact that it's a link is invisible. Yet, the GUI delete action still treated it as a link, not invisibly following it.
Either way, if a program does use the aliased name directly it will work. But having files sometimes seen with one name and sometimes the other could confuse things.
Conclusion
Use a Junction on the desktop with the folder really located elsewhere, and it will be completely transparent that this is what is happening. Optionally, using DACL to prevent accidental deleting of the junction point file on the desktop. At least, have a script to re-create it when needed.
Bonus
I've not tried this, but I wonder if you could have something in "new items" to re-create the junction or symbolic link? Then just right-click on the now-empty desktop, choose New... and pick "Desktop Junk" from the menu. Have it restore everything you really did want on the desktop.