If you would like to see a demonstration of the main point of this post then please see https://github.com/mwpb/web-attacks and navigate to the csrf folder. In that repository there are instructions about how to set up a some docker containers to demonstrate the various attacks.
Origin: Two URLs have the same origin if and only if they have the same scheme, host-name and port.
Site: The host's most specific public suffix AND the next specifier. This is sometimes written as eTLD+1 which stands for Effective Top-Level Domain plus one.
The 'SameSite' cookie indeed concerns itself with sites and not origins.
3 Same-site and cross-site requests
If a subdomain on the same site is compromised then cookies set by one will be sent to the other.
So strictly speaking cross-site request forgery (CSRF) is ruled out by setting SameSite=strict. However a similar attack may still be perpetrated by URLs on the same site but which are not under your control. This makes CSRF a confusing name because the same style of attack may still occur on the same site.
So the SameSite=strict cookies will still be sent. For the purposes of defence in depth in case a subdomain gets compromised: it is a good idea to use another strategy in addition to SameSite cookies. If you only support clients using modern browsers then you can check the Origin header on the server-side. Otherwise using CSRF tokens might be appropriate.