AES-CTR security if S-boxes substituion is omitted? I understand why s-boxes are needed in general especially when ECB mode is used(because of using the same key for encryption of other blocks)but I wonder if it's still relatively secure if we omit S-boxes substitution step in these circumstances

using AES-CTR mode to make sure the same key with the same blocks will encrypt to different ciphertexts
if we select a total random key

I'm asking since this way it seems that it's like we encrypting in a similar manner(not exactly) to one-time pad encryption since the result of encryption(that will get x-ored with plaintext) will be random. I know that using S-boxes will increase the security but is this way fine for non-top-secret documents, so we can get some extra performance for like embedded devices, without sacrificing too much in terms of security, also what kind of attacks can be used.
An Sbox is a necessary condition for the security of the AES or a similar block cipher but may not be sufficient. We can list all AES operations on a high level as

SubBytes – a non-linear substitution step where each byte is replaced with another according to a lookup table.
ShiftRows – a transposition step where the last three rows of the state are shifted cyclically a certain number of steps.
MixColumns – a linear mixing operation that operates on the columns of the state, combining the four bytes in each column.
AddRoundKey


wonder if it's still relatively secure if we omit S-boxes substitution step in these circumstances

If you omit the SubBytes then the new AES cipher will be a completely linear cipher. That is a complete failure for a block cipher. When the attacker, in the simple attack, gets a known-plaintext then they will set up linear equations in total 128 for any AES. If there is no linear dependency on the equation, then they can solve AES-128 with a single-known plaintext pair.
Your design has no KPA security and in modern cryptography, we at least require CPA security.

using AES-CTR mode to make sure the same key with the same blocks will encrypt to different ciphertexts

I've got two understandings.

You use a new key for each block. This is useless.

one uses so many keys to encrypt messages
Instead of this use OTP with the key that has other problems.
one needs to run the key schedule again and again


Use one key

KPA attack can break this.




this way it seems that it's like we encrypting in a similar manner(not exactly) like one-time pad encryption since the result of encryption(that will get x-ored with plaintext) will be random.

Not really random, linearly depend on the key.
Instead in modern Cryptography what we do, we turn a PRF or PRP into a stream cipher like CTR mode. PFR can work since CTR mode doesn't require the reverse of the PRF. So that we can use one key with one key schedule for a long time. AES-CTR or ChaCha are examples of among the many. AES is believed but not proven to be a PRP. And. remember that for CTR mode one should not use a key-IV pair again.
For file encryption, it is better to use AES-GCM or ChaCha20-Poly1305 which also provides integrity and authentication. AES-GCM is faster since the hardware support like the Intel's AES-NI. The blow in my machine for AES-128 NI
openssl speed -elapsed -evp aes-128-ctr
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     556160.77k  1822893.03k  3765397.08k  5115820.71k  5694253.74k  5739358.89k

If there is hardware support for ChaCha and Poly1305 it can beat AES.