> Putting actions in context menus means you replace "click" with "click,
> move, click".

I like your thought that considers the additional "effort" required by
context-menu access.  UI designers should pay attention to the
_number_ and _type_ of gestures required to operate the software.

>The buttons
> are a very clear indication of what you can do.

The context menu is a more-complete indication of what you can do,
though, wouldn't you say?  Because there are not buttons for every
single option on context menus.

> What are the alternatives?

Hot keys.  The context menus should indicate hot-key accessibility for
the most-used options.  Then, once learned, accessibility to that
function is made with slightly less effort than a button:

  1 - gross-motor point
  1 - press of the hot key (+ 0.5 if modifier required)
=========
  2.0 - 2.5 total gestures

With buttons you have

  1.5 - fine-motor point
  1 - press the red mouse button
============
  2.0 - 2.5 total gestures

Admittedly, this a tight a race.  But, in many cases, there's no good
reason for the UI designer to force the user use a modifier key..
Also, the additional cost of the buttons is the screen-space, and
clutter associated with that.  Also, buttons are usually not
co-located with the object on which to activate the button's command
(consider how awful "Office" applications have become, where you have
rows of icon buttons along the top or down the left side, and all the
"content" in the middle).  So they continue to reinforce
"global"-commands rather a more OO thinking, which is sad..

Let me say, I think there is a place for buttons and I do use them.
Just sparingly, though..