The system proposed with SHA-1 does not have the same level of security as AES-GCM.
@EllaRose's answer demonstrates how a malleable ciphertext may be manipulated. Malleable crypto systems are vulnerable to adaptive chosen cipher text attacks, and malleability is generally not a desirable characteristic. Authenticated encryption systems (such as AES-GCM) are used to prevent malleability: AES-GCM is not malleable; the AES-CTR+SHA-1 system is.
If SHA-1 were replaced with a better hash, whether SHA-256, SHA-512 or SHA-3, it would still be vulnerable to the attack in Ella's answer.
To materially improve it, the plain hash function needs to be replaced with a MAC such as HMAC. This would give a system that would probably be okay, as long as AES-CTR mode continued to be used; if that was switched to AES-CBC mode, it would be vulnerable to padding oracle attacks. (This is why the linked question and best practice recommend MAC-ing the cipher text, not the plaintext - i.e., MAC on the outside.)
(Note that HMAC-SHA-1 is still considered secure, despite the weaknesses in SHA-1.)
So to answer the question as stated, AES-GCM is objectively more secure.
If we broaden the question to: AES-CTR+HMAC vs AES-GCM, we might be able to create an answer.
In AES-CTR + HMAC, if AES gets broken but HMAC is not, we could detect a modified cipher text, but we would likely lose confidentiality. If HMAC was broken, but AES not, (hypothetically, since there are security proofs) we return to plain AES-CTR, which is malleable.
So, in other words: in a system that uses two primitives to build a crypto system, if either primitive fails the system fails.
In AES-GCM, if the AES part is broken, then both confidentiality and authentication (integrity) are lost; if the GHASH is broken, authentication fails. And if authentication fails, we are back to AES-CTR, which is malleable.
How much future proof the above method would be in comparison to AES-GCM or any other method where auth tag is made public?
If the GHASH in AES-GCM is broken, it will be big news. You will know about it. And hashes are normally broken gradually, so there should be time to prepare. The same is true of a hybrid AES-CTR+HMAC mode, except you would need to remember that you are using HMAC with the AES encryption.
And in building a hybrid crypto system, you have to ensure you put the correct primitives together in the correct order.
Ultimately the question comes down to which has higher chance of getting cracked in future? AES-256 vs HASH Algorithms.
Actually, in a constructed system like AES-CTR+HMAC, if either of the primitives fails the overall system fails. (Otherwise there would have been no use in having used the part that failed.)
If AES_256_ENCRYPT_CTR(key, sha-1(plainText)+plainText) is more secure, why in TLS 1.3 AES-GCM is used?
Well, it's not more secure. But for the hybrid constructions that are, using a single mode to provide authenticated encryption is safer, because there's less for the users of the cryptography (i.e. the TLS designers and implementers) to get wrong.
(And if weaknesses in AES-GCM are found, we will get a drop-in replacement; if problems are found in either AES-CTR or HMAC, we have to figure out how to circumvent those issues where the two are used together.)