In this answer, I will only consider the discoverability of features and not discuss the mere graphical design, or aspects such as the size occupied (as they are very implementation-specific).
In my opinion, there are two aspects in the discoverability of features:
The first is discoverability by the user without any external information: Just by visually scanning a ribbon, one may or may not be able to recognize a particular feature. Without knowing what ribbon a given feature is placed in, one has to switch through each tab, just like what one could do with menus.
A slight disadvantage of ribbons in this respect might be that the buttons are "all over the place"; they come in different sizes, and their layout is (while rectangular), accordingly "chaotic" (for an example, have a look at the Slides group in this screenshot). This is in contrast to menus, which have two clear columns (one for icons, one for the command title).
What is more, some of the icons on Ribbons lack the text, which is not helpful if you are looking for a command and have a certain idea of what it's called, but no idea how its icon would look like. Like this, commands can hide "in plain sight" on Ribbons, which is never the case in menus.
The second aspect is discoverability by the user based on instructions: In my opinion, this is where Ribbons are incredibly weak compared to traditional menus.
The first issue in this respect is related to Ribbons not showing any text for some of the commands. For a menu structure, textual instructions (on a tutorial website, in a book, in a chat window, or spoken on the phone ...) can very easily relay where to find a particular command in a menu (fictional example, for (intentional) lack of an MS Office installation on my computers): "Click Edit -> Import -> From File -> Via Plugin. The same is rarely possible for Ribbons, as some icons do not display any text, and texts are displayed in different locations. For an example, refer to the aforementioned screenshot once again: Some texts are on the right of icons, some below, group headers are below, ribbon headers above.
Essentially, it is the same reason why, with traditional menus, such instructions would usually refer to the menu rather than the toolbar.
Furthermore, in menus, going to the next level of hierarchy is a straightforward activity that works the same way on each hierarchy level: You hover over/click a menu item, and a nested submenu appears. In Ribbons, on the other hand, each level of hierarchy works differently. Sometimes, it is a tab, sometimes, a group (in the case of groups, no input is required, just visual scanning), sometimes, you need to click on a group header to open the "group dialog box" (and even that is not uniform, as some groups do not have a dialog box and their headers are not clickable), sometimes, you need to open a dropdown menu from a button, which makes the whole process very confusing.
P.S.: A lot of answers seem to mix up what is and what is not part of the "Ribbon interface" as such. One of the most controversial properties that is often cited in answers here and elsewhere seems to be the reorganization of a variety of options. Those who praise Ribbons sometimes praise them because they perceive the grouping in Ribbons more logical, while those who dislike Ribbons (and also those who talk about users who dislike Ribbons) often point out that users used to the old menu structure are used to the old grouping of commands and thus are annoyed because they have to relearn where to find commands. However, that change merely coincided with the introduction of Ribbons in MS Office, it is not inherent to the Ribbon interface. The very same reorganization could have been conducted in the old menu structure. Hence, commands being grouped in a more logical way and users being averse to change and having to relearn may both be true and valid points, but they are unrelated to the Ribbon UI.