No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
- padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would likely be vulnerable to padding oracle attacks; they are not avoided by the mode itself.
- stream cipher attack, because it isn't just simply XOR-d
Although you would not be vulnerable to a many-time-pad if the nonce is repeated, you would of course still leak information on each block of ciphertext that is identical, at the same location. That's slightly worse than e.g. CBC mode, where a change in plaintext would change all next ciphertext blocks if the IV is ever repeated.
- malleability, because XOR-ing something on the ciphertext changes the entire plaintext
It doesn't, it just changes on block of plaintext at the same block offset. You would still be malleable if you would change the entire plaintext by the way (imagine encrypting a single bit, 0 for false or 1 for true!). So you need to expand your ciphertext - usually with an authentication tag - to avoid malleability. This is not a description of an authenticated cipher.
A significant disadvantage is that it needs a new key expansion for every element of the keystream.
Correct. And because you are using a lot of keys, you may run into trouble with regards on how the key space needs to be treated for a specific cipher. You would definitely worry about keys repeating simply due to the birthday paradox.
Are there any more advantages to this architecture?
Not that I see, it adds an additional round that introduces problems, while solving none; counter mode is already considered secure. With double the additional rounds + a key schedule per block it is rather expensive for what it tries to achieve.
Any further disadvantages?
I don't think we need more disadvantages, but I'll show some for learning purposes.
One disadvantage is that your key and block size need to be identical. So using e.g. AES-256 is not possible (even if it would be advisable because you may not want to use a cipher that is vulnerable against related key attacks, even if those are mostly theoretical in nature).
You would lose the pre-computation benefits of counter mode, where you can cache the key stream. You can still do that of course, but the last block encrypt / decrypt can only be performed once the plaintext is available.
