Text color is enough for that purpose. In most editors I’ve used, I can clearly see the comments, the keywords, the strings, etc. There is simply no need to visually complicate stuff with background color.

Another element is that backgrounds are used, but for the purposes other than syntax highlighting. For example, in Visual Studio:

• Background colors are used to highlight the current line (not the configuration by default) as well as the matching brackets or every use within the file of a currently selected variable.

  This alone is a good reason not to use backgrounds for syntax highlighting. Changing background to highlight the occurrences is a very powerful visual way to show information if and only if the background stays uniform elsewhere.

  

• Yellow background is used for quick search.

  This is another good example. You can see in practice how difficult such search becomes in a browser when the webpage uses too much background colors. You simply can’t see where the search occurrences are.

  

• Dark red background and yellow background are used when debugging.

  

• Light yellow, light blue and light red are used to show the results of code coverage.

  

• Other colors are used during a diff in TFS to highlight added and removed text.

  

Not using background colors for syntax highlighting makes it possible to keep background colors for something special. If you already use backgrounds for syntax highlighting, you’ll end up with a visual mess.

Your example of Greenfoot Editor is a different illustration. They use background for nesting, so using it also for syntax highlighting would create a mess too. Note that their case is problematic too; not, like you said, “if you are doing some more complex work and there are more nested conditions”—if your code has five nested levels, you’re screwed anyway and your first concern should not be the IDE, but the code itself, but rather because if the code is formatted correctly, nesting is visually clear, and there is no need to add colors.