What you've said is exactly right. Anyone who has ever called a locksmith because they were locked out of their house or car understands two things:
1) They weren't able to get in without the key - it was secure.
2) The locksmith got in without a key, probably in under 2 minutes. It was not secure.
Security is a quantitative thing, not a binary thing. You can ask HOW secure something is. Asking "is it secure, yes or no?" is folly.
Standard TLS (https) is much more secure than plain text (http).
Standard TLS connections are useful in the same way that physical locks are useful - they make it unlikely that anyone will in fact defeat your security. Both *can* be defeated by a skilled person using the right tools, given they invest enough time in doing so. Both are more secure than leaving stuff wide open for any passerby to take.
Self-signed certificates are slightly more secure than plain text on a *technical* level, but because they may create an illusion of strong security where none exists, they may be less secure in practice.
We have customers using self-signed certs (without pinning) who mistakenly think the self-signed certs prevent MITM attacks, so they send sensitive data over these connections, "secured" by TLS using self-signed certs. They'd arguably be more secure overall if they understood they have no protection on those connections, so they wouldn't use them for sensitive data (or would encrypt the data before sending it over the non-secured connection). A misunderstanding of the "protection" offered by self-signed certs leads them to do something foolish.
In this regard, there is a counterpoint to what I said above about it being folly to ask "is it secure?" as a yes or no question. It may be wise to try to create a binary secure/non-secure label in order to ease understanding. Weak security can fool users into thinking it's "secure", so it may be better to either secure something strongly or not at all, so users can easily tell that it's obviously not secured.