But there's almost always a better way to present it to the user. If I'm viewing a news site, I'm not going to think that the hamburger menu is where I go to find the Lifestyle section. If you absolutely must hide your sections behind a menu, there are practically infinite different menus that make more sense.
The hamburger menu only makes sense when it's the literal junk drawer of the app/site, when there's no possible way to categorize its contents with anything more than the completely generic 3 horizontal bars. But primary navigation elements are not junk and don't belong there.
This a a little hyperbolic. If you want surface a link to the Lifestyle section, then you also have to accept that links to about a dozen other sections need to be visible as well - on mobile, this would lead to about a third of the visible page (or more) being consumed by navigation links. Alternatively, you put the nav at the bottom of the page, but I would argue that doing so makes it less accessible/visible than it would be in a hamburger menu.
The real challenge is not when you're trying to put 3-4 links or nav-groups in a hamburger menu, but when your site structure is so flat/shallow that you have a dozen or more equally-viable nav/action options for users. Except for the NBC example in the article, the nav in the examples can be distilled into a narrower, deeper structure.
The article author doesn't appear to realize that on NBC news, the hamburger-equivalent "more" menu still appears at mobile widths. Sometimes it really is a decent solution.
This is a big part of the problem. Devs too lazy to use media querys to adapt the layout to the screen. We end up with poorly implemented "mobile" sites on our big, wide desktop screens. It's like the web took a step back to 1995 with pages hardcoded for 640px width. Looks good on my iPhone... time to deploy.
A hamburger menu that can be optionally converted to a persistent sidebar on screens with sufficient space would alleviate much of the usability problems.
You seem to have completely missed the entire point of my comment. In no way am I saying that a news site needs to have a link "Lifestyle" visible to the user at all times. In fact, you quoted directly from the most relevant point, the bit that says that there are practically infinite different ways to design a menu that avoids the problem of the hamburger.
As a trivial example, you could have a single menu labelled "Sections" with a disclosure arrow, and mousing over / tapping it would then reveal a list of all sections. It's functionally identical to the hamburger in actual usage, but because it's called "Sections" (and only contains sections, not arbitrary junk), it becomes an obvious thing for users to interact with if they're looking for the Lifestyle section.
> You seem to have completely missed the entire point of my comment
This is a little hyperbolic. You've basically recommended a labeled hamburger menu - 'Sections' instead of 'Menu' - and text labels definitely have a demonstrable advantage over icon-only buttons, but the OP isn't advocating for text labels instead of the hamburger icon (see NBC example that had a labeled hamburger menu originally), it's proposing that the menu items be surfaced into tabs, segmented controls, and lists. That's not viable on sites with a flat structure.
nytimes.com uses the hamburger icon with the 'Sections' label, as you suggest, but it's important to acknowledge that this is just a variation on the theme, not a complete rejection of the 'menu items hidden behind something else' principle, so we need to be precise about the problems that a hamburger menu can and can't solve.
It's not just about labelling, it's also about not putting everything into the same generic menu. And I completely agree with the original article that anything[1] that you can pull out of the menu entirely and turn into a top-level element, you should. But freshyill's comment was specifically about large sites, such as news sites, that have too many elements to put them all at the top level. And in the context of that, I'm saying that the hamburger menu is still the worst solution you can come up with. If you must hide things behind menus, group them in a way that makes sense, with a label that tells the user immediately what the menu will contain. If the user has to actually open the menu to find out what's in it, then you've already lost, because it means the user won't know to click on that menu when searching for a thing that happens to be in it. For a news site, if the user wants the Lifestyle section, they'll probably understand that clicking on a menu named "Sections" is likely to give them what they want (or perhaps clicking on a menu labelled "More" right next to a few of the most popular sections such as World News). What they won't figure out without guessing blindly is that a menu with an icon of 3 horizontal stripes is where they can find the sections list.
So basically, what I'm saying is that if you must use a menu, label it appropriately, and only put relevant items in that menu. If you have a bunch of things that aren't related to each other, they should be in different menus. A real hamburger menu is only appropriate for items that the vast majority of users are expected to never click on, and for which you're ok with making it hard to find for the rare user that actually does need it.
[1] Well, anything that you want users to actually click on.
Practically anywhere else. If I really wanted to find it, I'd probably eventually click that hamburger menu, but the only place that I'd be even less likely to look for it is the footer of the page.
In a mobile app it makes a lot more sense, because screen space is so limited and the hamburger button will occupy one of the prime navigation points in the app UI (typically the upper-left or upper-right navigation button slots), so there's obviously not very many possibilities to find something, but even there, if you can possibly avoid using it, you should. As the original article demonstrates, hiding your navigational elements, even on mobile apps, significantly reduces user engagement.
In a desktop website, I can't think of any reason why I would ever use a hamburger menu. Other, more specific menus, sure (e.g. "Sections" in a news site). But if I see the hamburger menu, besides thinking that it's really out of place when not in a mobile app, I also will instantly assume that it's the place to find things that I probably will never need. Basically, if it's something that you might put in the footer of your site, then hiding it in a hamburger is fine. If you think it's something that enough users will want such that the footer would be inappropriate, then don't put it behind a hamburger either.
The hamburger menu only makes sense when it's the literal junk drawer of the app/site, when there's no possible way to categorize its contents with anything more than the completely generic 3 horizontal bars. But primary navigation elements are not junk and don't belong there.