HTTP (the Hyper-Text Transfer Protocol) is how websites are accessed. It's used in requesting the page that you want, and everything on it, and it's used in sending it to you. You'll see http:// prefixing the website address of most sites you've visited, setting the method used for accessing it.
HTTPS is the secured version (that's what the extra S stands for). A service has a security certificate that's used to confirm they are who they claim to be, that some other trustworthy organisation has verified in some way (or is supposed to have done). And the data sent back and forth through the connection is encrypted. So there is a certain level of security and privacy. And you'll see https:// prefixing the website address of many other sites that you've visited, setting the method used for accessing them.
For me it's use a secured connection, or don't use a secured one, as the needs of the situation demand. But don't do half-arsed security that only pretends to be secure.
Should every website be HTTPS?
No. They don't need to be. If I'm looking up a bus timetable, browsing a product catalogue, or the TV guide, there's nothing that needs to be confidential about that. But if you're about to put yourself at any kind of financial risk, then you should definitely make sure that you're using HTTPS.
Can every web service be accessed using HTTPS?
No. Many don't have a server that uses it (such as lots of personal websites), although it's quite normal that most public websites can be accessed either way, and many will bump you over from their HTTP site to the HTTPS site automatically, either as soon as you connect, or when it comes to doing something that needs security. And now many web-browsers are doing this automatically, but not always very wisely.
As well as there being a lot of public sites without HTTPS, there's a variety of gadgets within our home networks (printers, routers, etc) with a built in webserver for configuring them that have no facility to do HTTPS, or use a self-made and self-signed security certificate that my browser quite-rightly warns me has no trustworthiness to it (it's not been cross-checked by some trusted third party, and anybody can fake such a certificate), or has a security certificate that is out of date and cannot be renewed (and my browser may refuse to connect to the service, simply because of the date), or that type of encryption is no-longer supported and can't be used, at all (and I'm certainly not buying a new printer just because the web-browser thinks it's too old).
Are there disadvantages in using HTTPS?
Yes. Encrypting all the data requires more work by the computer systems on both sides of the transfers (you and them). In this day and age of modern high-speed computing, it's not too much of a burden on your computer (unless very large files are involved). But for a large serving farm that hosts thousands of sites, it will be a significant burden. More processing uses more power, that needs more cooling, that uses more electricity, which is an environmental problem. So there's certainly arguments for not using it when it's not needed.
Are there advantages in using HTTPS?
Yes, of course there are, that's why it was invented.
When it's done properly, and you check that it is, you're assured that you're connecting to the service that you think you are, that your information is protected in transit from snooping and interference. But it's still up to you to check you're not being scammed.
Are people over-confident about what it provides?
Yes.
If you do not check that when you think you're connected to your bank that you actually are, it's not protecting you. If someone can register a website and certificate that's almost the same as your bank (a minor mis-spelling that looks very similar), it won't help you. This can happen with certificate providing services do not adequately vet people setting them up, don't check the similarness of their name with existing entities, and don't query or reject it. The more automated they are, or the use of low-paid low-skilled telemarketing staff, the more susceptible they are to allowing it. And can happen when users don't bother to check, or know anything about it.
If you allow your browser to connect to a site where the certificate is not vetted by a trusted third party, you can easily be connecting to something fraudulent. These days browsers can warn you about such thing—the level of trustworthiness, or not (of the certificate, itself, but not about the nature of the site). A low level of trust will be fine for a personal or informational website, but not for where money, security, and real privacy is involved.
If you allow a connection to a site where the certificate is out-of-date you may be connecting to a service that is no-longer under the control of the same people. A genuine commercial site is probably going to get that fixed fast. So wait, try again later, or the next day. But be highly suspicious of something much more out of date.
It doesn't provide absolute privacy. The data sent through an encrypted connection is private (to the level of computing power available at the time, and it depends on what the website does with your data), but the fact that you've made a connection to that site is not private. It's a bit like knowing that someone has phoned their doctor, and which doctor's office they phoned, but not knowing what the conversation was.
And it is not a seal of approval, HTTPS merely encrypts the data, whatever it is. A security certificate issuer may, or may not, check whether they're certifying a trustworthy site. And what appears to be trustworthy at one point in time, may change later on. Or deliberately show a different version of themselves to any vetting agencies than the general public will see. There are always confidence tricks going on, continuously, on the internet.
What is in the security certificate?
Identifying data that names the website(s) and entity it's for. However the organisation's name might be some obscure trading name that means nothing to you.
Identifying data that names the organisation(s) that issused and/or verified the identity of who the certificate is for.
Information about the kind of security encryption associated with it, and it's potential uses (which may just say “digital signature,” though it could list things like signing of other certificates, encryption, authentication, and domain name validation, etc). It could just verify that you're connected to the website that you think you are, but have no use in verifying the people running the website.
A digital fingerprint of the certificate that you can use to cross-check its validity (using information you've received through another source).
However, if you want to know what level of trust you can place in it, you will most likely have to go to the issuer's site to see what kind of cross-checking they demand. Do they view personal identification, what kind of identifying information do they look at, do they check corporate records, etc?