Cannot scroll in small areas

Yes, I'm seeing this too.

in these cases, I should not show the thumb, and let the user use the mouse wheel or the keys

@Andrea: IMHO, that behavoir wouldn't be easily understood by users that expect a thumb to drag like they always do. I'm not an expert in this field, but personally I would feel uncomfortable with that solution.
In addition, in that way the user can't know whether or not it can drag the scrollbar until he moves the mouse over it... and this will be a useless movement.

the design was tested with the solution I wrote above... and remember not only these cases are absolutely rare, but also that people are not using the thumb too much, the scroll wheel or two-finger scroll is the common behavior now a days

A solution which does not let the user scroll with the thumb is inconsistent, damaging the feature as a whole, and possibly problematic for people with limited hardware, as in your suggested solution.

In my case, I prefer to use the thumb, so having that not "just work" wherever I see a scrollbar is confusing. Not only that, but I frequently work on a Thinkpad which has neither a scroll wheel nor a track pad to support "two finger scrolling".

Unless you have hard data to the contrary, and a policy which explicitly supports excluding a known portion of your users, I'd recommend against any justification which relies on people interacting with their computer in precisely the way you do. Otherwise you risk creating one of the thousand cuts which make an interface just too painful to use.

@Andrea: I do agree with Alex that this behaviour is inconsistent and far from ideal. If it is really the intended design, it should at least be communicated more clearly: For example, in the design blog entry[1], it is stated that "Scrolling via thumb" has second priority (after "scrolling via mouse wheel (or dragging content on touch devices)") -- your statement "let the user use the mouse wheel or the keys" seems to suggest that using the keys has higher priority.

Furthermore, after the fix you suggest, anyone testing using the Desktop tracker[2], following the test guidelines for the scrollbars[3] would have to file a bug like the OP did: Point 3 of the testing procedure clearly states:
"verify that scrollbar "thumbs" do appear when approaching the scrollbars: the position of the thumbs should be outside, on the right, of the window containing the content pane, except when the window is close to the screen border, in which case it should be appear inside the content pane"

[1] http://design.canonical.com/2011/03/introducing-overlay-scrollbars-in-unity/
[2] http://desktop.qa.ubuntu.com/
[3] https://wiki.ubuntu.com/Ayatana/ScrollBars

This bug was fixed in the package overlay-scrollbar - 0.2.3-0ubuntu1

---------------
overlay-scrollbar (0.2.3-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - New thumb design.
    - Scrollbars now use Gtk+ colors.
    - Scrollbars are now less rounded.
    - Support RTL locales and different scrolled window placements.
    - Added tolerance to pageup and down buttons before dragging.
    - Adjusted timings before hiding the thumb.
    - Shrink the thumb size on small scrolled windows.
    - Cannot scroll in small areas (LP: #771450)
    - support left (and top) scrollbar placements (LP: #761138)
    - Overlay scrollbars do not work in right to left locales (LP: #782022)
    - emacs23-x crashing in liboverlay-scrollbar-0.2.so.0 (LP: #800387)
 -- Ken VanDine <email address hidden> Thu, 30 Jun 2011 17:45:35 +0100