Considering password strong enough so it is will never be a weak point (lets say 100 chars, uppercase, lowercase, number, specials) can password based encryption be as secure as just using the key itself, or does it always allow to infer a smaller set of possible keys?
No, as long as you are able to "compress" it into a key with a suitable KDF then it is fine. Most encryption algorithms do not allow for such long keys, so compression seems a necessity. You could use a PBKDF with a single iteration or a KDF such as HKDF.
This is: assuming that the password can indeed not be guessed (they aren't alterations of a previous password, etc.). But I think that's what you meant here.
Same as above, but in context of gpg (assume strongest hashing algorithm with maximum number of rounds - --s2k-digest-algo and s2k-count)
Sure, and I would think that even the default hash (RIPEMD160) would be fine unless you need more than 128 bits for the keys. Obviously I'd rather use SHA-512.
As the worst case scenario for an attacker is to have to brute force guess the 256-bit key, does it make more sense to just store the key itself? (Assuming that either password or key need to be stored, as they are both too complicated to remember)
Sure, you could go for a base 64 encoded key. It depends on the runtime which is easier.
If answer to 3 is yes, then is openssl AES265 with specifying a key directly a good method of accomplishing that? From research I have done, you can not use a key directly with gpg.
You could use it instead of the 100 character password. At least you'd have relatively few special characters (you might want to use base64url, I'd expect underscore and dash are less troublesome than +, / and =). And 32 bytes in base64url are just 43 characters. Beware that most password managers provide methods to generate passwords though, not encoded keys.
