the Online Community is NOT Secure

Thinking https will solve the concern of non-members seeing members only profiles, misunderstands what https is, and what it does. This is ONLY about the data IN TRANSIT. Think of the difference between a  letter and a postcard in the mail. One has the contents on the outside, readable by all who see it, the other only has a name and address, the content is inside. This is the same principle. All https does is put that sensitive info in an envelope (to carry on the analogy) while it goes to the server. When it's there, the server has to see what that content is. It puts it into the database. The website itself then builds the pages we visit, like member profiles, by asking the database for the content. The thing that prevents non members from seeing members profiles (as the example above) is the code on the site itself. Only the webserver should be able to read and write to the database, and the permissions on the pages like profiles mean that unless you're logged in (aka be a member) you won't see any. Try logging out, then looking at any members profile, including your own. You get diverted to a log in or register page. The only concern beyond that would be if someone managed to break the database. Most of the time this is unlikely with any halfway competent sysadmin and some common sense IT safety.

Like everything in life, nothing is perfect. There are plenty of sites that fail in a lot of basic ways, so I wouldn't use them. I don't have any concerns about using this site. Sure I'd prefer there'd be more server capacity or load balancing as it's slow or inaccessible at times. I don't attribute that to anything more than "we're a small charity with a limited budget and manpower, we're doing our best". I wouldn't use ASPX or Windows Server but that's a personal thing. Often you don't control these decisions. There's often a history of existing infrastructure to maintain that you wouldn't necessarily choose if you were building today,

Another sign that it's about limited resources, is that it can't maintain a connection when logged in, specially after closing the browser and reopening it, You have to log back in. This is a sign that there's only X number of threads available, so you don't get much of a claim on one. It has to be quite stingy in pulling it away from you when it thinks you're not using it, so that someone else can use it. This is what you do with very limited resources, you spread them as thin as you can, while still being practical.

Thinking https will solve the concern of non-members seeing members only profiles, misunderstands what https is, and what it does. This is ONLY about the data IN TRANSIT. Think of the difference between a  letter and a postcard in the mail. One has the contents on the outside, readable by all who see it, the other only has a name and address, the content is inside. This is the same principle. All https does is put that sensitive info in an envelope (to carry on the analogy) while it goes to the server. When it's there, the server has to see what that content is. It puts it into the database. The website itself then builds the pages we visit, like member profiles, by asking the database for the content. The thing that prevents non members from seeing members profiles (as the example above) is the code on the site itself. Only the webserver should be able to read and write to the database, and the permissions on the pages like profiles mean that unless you're logged in (aka be a member) you won't see any. Try logging out, then looking at any members profile, including your own. You get diverted to a log in or register page. The only concern beyond that would be if someone managed to break the database. Most of the time this is unlikely with any halfway competent sysadmin and some common sense IT safety.

Like everything in life, nothing is perfect. There are plenty of sites that fail in a lot of basic ways, so I wouldn't use them. I don't have any concerns about using this site. Sure I'd prefer there'd be more server capacity or load balancing as it's slow or inaccessible at times. I don't attribute that to anything more than "we're a small charity with a limited budget and manpower, we're doing our best". I wouldn't use ASPX or Windows Server but that's a personal thing. Often you don't control these decisions. There's often a history of existing infrastructure to maintain that you wouldn't necessarily choose if you were building today,

Another sign that it's about limited resources, is that it can't maintain a connection when logged in, specially after closing the browser and reopening it, You have to log back in. This is a sign that there's only X number of threads available, so you don't get much of a claim on one. It has to be quite stingy in pulling it away from you when it thinks you're not using it, so that someone else can use it. This is what you do with very limited resources, you spread them as thin as you can, while still being practical.

I have not misunderstood HTTPS.

As WebPM noted, the trend "is towards HTTPS throughout sites". Doing that help improve security for users.