Secure => Attacker can't simply inject an img to a non-https version of the site and then intercept the cookie sent by the browser, therefore stealing the session.
HTTP-only => An XSS attack can't steal the session cookie. You're still in big shit, but it's much harder to persist the attack beyond the user closing the browser window.
It is security theater. Real attackers don't sit there waiting for a cookie to arrive so they can start to craft their malicious authenticated requests. If they can write a script to steal your cookie, they can also write a script to execute the actual requests right there in your session. And httpOnly cookies do not prevent that at all. Security theater is worse than nothing because you think you're secure from XSS, when you should know better.
The "Secure" flag has nothing to do with protecting against XSS. It protects against anyone who can proxy your requests (i.e. when you connect to dodgy wifi) being able to steal your session simply by injecting <img src="http://yoursite.com"> into any non-secure web page your request. That is a massive security hole and not theatre in the slightest.
The HTTP-only flag is less important but still useful. As I said, you're still in deep shit because of course they can make actual requests and if you think it's all you need to protect you then that's a problem. But there's still a difference between an attack that can be persisted, and one that gets interrupted as soon as the user navigates away from the page.
I'm talking only about the httpOnly flag. It's worse than useless because it makes you think that you dodged some kind of bullet, when in fact that same class of attack can still happen: the attacker needs to craft a script to send the cookie to their server, so they might as well have that script execute the actual requests in the context of your authorized session, the same way that they'd do it if they had your cookie. They would write the script ahead of time. No real attacker would sit there at 3 AM making requests because their victim finally activated a script that sent them the cookie. Far more likely, that script is already pre-programmed to do what it needs to do. And if httpOnly cookies didn't exist, the people would care more about sanitizing their Javascript output to prevent XSS, which is the only correct way to prevent this attack.
For what it's worth, I agree with the criticisms of HttpOnly, but I still recommend people set it as one of several redundancy measures.
The approach I take these days (for example: when I gave a three-hour tutorial on web app security at DjangoCon this week) is basically to provide combinations of basic mitigations and then more complex/advanced ones, and push people do at least some combination of them, even if they can't do all of them. So to take XSS/CSRF, for example: Django's template system autoescapes variable output by default, and there's a CSRF protection mechanism on by default. Those are the basic easy things, because the advice is just "they're on already, don't turn them off", and just those simple measures will deal with a lot of nastiness for you.
From there I can talk about cookie options, or CSP, or that kinda-sorta-works header that turns on reflection detection in a few browsers, and the pros and cons of each, and recommend people use combinations of them. CSP is my gold-standard recommendation nowadays, and I downplay HttpOnly as not super great, but I'm not going to complain if somebody just watches my talk and does all the things mentioned.
That is just security theater. It's worse than useless because it makes you think you're more secure, when you haven't prevented attacks are all.