they are in a different origin, am I missing something?
You might be missing something regarding HTTP cookies but it's probably not the main issue here, but it's important to fully understand the subtle aspects of cookie semantics because they are widely used for security sensitive purposes.
You can only read cookies by JS if they are associated to the page and sent to the server in the HTTP request: it's a necessary condition (but not sufficient obviously as cookies can be made "HTTP only"). So what you are saying is that an HTTP request to an URL with origin A only sends cookies set by pages from A. But this is not true.
Actually you very often get cookies from a different (but not arbitrary) origin:
https://x are different origins, but HTTPS URLs receive HTTP cookies (and there is no way to refuse that or even sort out cookies by actual origin); the common fix for that is to make a domain HTTPS only in the browser via prelisting or HSTS headers.
for any secure or insecure scheme,
sub.domain.register can share cookies: cookies set in domain are visible in the subdomain, the subdomain can choose to make some cookies visible at a wider domain, limited to "register", the domain where the browser believes people can register domain (which isn't even always a perfectly well defined concept); again there is no way for a server to determine who set which cookie, so unless you control all every related domain you might get additional cookies.
Not only that, the interaction of cookies of the same name was never well defined and browser independent and different browsers had different behavior.
Now by hypothesis an attacker cannot invent an arbitrary subdomain in your domain and make a secure connection to it work; if he could, it would be as easy to just intercept a secure connection to the main domain, as by hypothesis the attacker would either be able to get a certificate that he isn't allowed to get, or to make users dismiss security warnings. So if you set a secure cookie for domain, the attacker can't intercept it by playing with subdomains.
The purpose of permission/authentification cookies
Back to the original issue, which was never to protect a cookie value but the rights linked to an authenticated requested, linked with an arbitrary and meaningless value: a cookie as in the older X server authentication cookie is just a meaningless number that has no value in itself, only in connection with a server that attributes meaning to that cookie.
You are not just trying to keep a numerical value secret, you want to protect the functionality of that value. Say you have an electronic card containing a secret key that can't be copied, and that can only be used on a safe to open it; if the card can be stolen from you and used without your knowledge, the content of the safe isn't secure; although the secret code was always inside the card, and no attacker ever learns that code.
Protecting HTTP cookies that represent a permission on the server (or an authentification status, or anything that a random anonymous user on a website cannot do) means preventing the cookies from being misused even in ways that don't allow an attacker to learn a meaningless numeric value.
[Note that the designers of the HTTP only flag explicitly warned against over reliance on it as a protection against JS injection - something that many people decided to ignore thinking that the "HTTP only" is only needed protection against XSS for sites that have valuable authentication cookies.]
A secret cookie protects access to a Web ressource and allowing arbitrary operations to be done by any external agent (running on an arbitrary domain) via a browser defeats the purpose of protecting that secret - even if the secret says secret, like an access card you would let anyone use.