Stream ciphers create a key stream that is combined (normally XOR-ed) with the plaintext - just like the key stream for an OTP. AES-CTR (and the derived modes such as AES-GCM) can generate the computationally secure key stream you are looking for.
- is length requirement only issue in this kinda system?
For a perfectly y secure OTP, it is maybe the only issue (if you don't include integrity / authenticity, message size & frequency etc. etc.). However, it is also a problem that is theoretically impossible to solve, as it would take as many bits if you want to increase the key size - in other words it is impossible to increase the key size on both sides without destroying the security of the OTP.
- couldnt we compromise speed a bit (during stretchin) for in return getting such a strong notion of security, making computation irrelevant?
Computation is irrelevant for AES-128 (or AES-256 if you require quantum safe cryptography), assuming that it isn't used for a specific attack different from brute force.
- couldnt we not even take away AES part but rather put otp in between as another layer? (note that since there'd be stronger notion it could in return reduce low bound of AES key size)
No, I suppose, although you have never shown where / how AES is used in your question.
- could otp be considered as security by obscurity - hence very nice reason to not use it?
No the theoretical notion of an OTP is exactly the opposite. It requires a lot of key material to obtain perfect security instead of (almost) no key material to simply hide the message instead.
Note that simply applying any of these modes doesn't mean that your protocol is necessarily secure; as an example an attack such as EFAIL relies on altered plaintext to exfiltrate any message from email clients; in general you want to use an authenticated mode of encryption.