I think you are confusing Access Token with Authorization Grant.
When a user authenticates against the Authorization Server (AS), the server will generate what's called an Authorization Grant that contains all the relevant information such as the scope, issuer, expiry, etc...In most implementations thess grants will be persisted to a database or similar persistent storage. The Access Token that the client receives and then sends to the Resource Server (RS) will be just some kind of opaque string that uniquely identifies a valid authorization grant generated by the AS. So the access token alone does not have any meaning per se.
This means that the RS has no way of validating access tokens by itself, only the AS does. The RS can validate the syntax but it will need to send the Access Token to the AS for validation. This interaction between the RS and the AS is not part of the OAuth 2.0 standard, as mentioned in the answer that you posted, and it's up to the AS implementation to decide how to accomplish this task.
Even though you're right when you say that any hacker can generate random access tokens only the AS can generate and persist authorization grants. That's the main reason why your RS should always contact the AS to verify the validity of the authorization grant linked to the access token before granting access to any resource.
I hope this clarifies your question.