If you can't trust, say, a url or an IP address. Then you can't trust those things to host a source of randomness either. Security is only as strong as the weakest link, if you try to obfuscate a weak-link by surrounding it with impressive looking junk, that doesn't make it stronger.
You need an external source of entropy to generate the key material required for any cryptography. It can't be in your code because any code is fundamentally incapable of doing that. If your source of entropy is compromised, then none of cryptographic systems are safe, not symmetric, not asymmetric, not one-time pads, not anything else.
Yes, you can't trust an url or an IP address - but you should be able to trust your hardware, and that commonly offers some decent sources of entropy. You can also trust yourself - e.g. user-action derived entropy. If you don't trust your hardware, tough luck, get trusted hardware. If your key material isn't generated properly, then your crypto will not be secure.
It doesn't mean that the method is flawed or insecure. All methods are the same in this regard, it simply means that security requires not only secure code, but also other precautions - e.g. secure generation of keys, secure management/storage of keys, secure platform on which to run your code, etc, etc. If you have a secure algorithm, proper implementation, best practices everywhere else, then your system will still be insecure if you fail e.g. to store your keys securely and someone gets them.
Take Alice and Bob, who want to communicate confidentially. Alice doesn't know Bob personally, so she can't securely communicate the one-time pad to Bob in person. Ethereum implements public-key cryptography, so she uses Bob's public key to send him the one-time pad's key. But now we're at the chicken and egg problem: we've just witnessed secure communication, so why do we want to use a one-time pad in the first place?
Alice and Bob might respond, "so we can have perfect secrecy at some point in the future!" Which...alright, sure, let's go with it. So now to implement the one-time pad in Ethereum, Alice needs to feed a source of true randomness as a seed for a secret key which is as long as the plaintext. This is not only a genuinely hard problem, but it's grossly inefficient to encrypt something using a secret key as long as the plaintext itself. But wait - for every new plaintext, Alice has to do this true random seed song and dance each time to generate a new secret key. And every secret key ever used needs to be kept perfectly secret as well.
You really just don't want to do this. One-time pads barely made sense in pre-modern cryptography; they don't solve any practical problems in modern cryptography, and their demands require steep usability sacrifices that are quite easy to screw up.