But, it seems that most discussions focused on double-spending (like broadcasting two or more conflicting-but-valid transactions, or Finney attack), instead of the validity of the transaction.

That is because a transaction being 'valid' is somewhat inconsequential when considering whether or not a payment has been made. What does matter is that the transaction is confirmed in the blockchain record. Even a single confirmation may not be enough, and so waiting for several confirmations will mean a higher probability of a permanently confirmed payment.

Obviously, an invalid transaction is no good, but there are also no guarantees that a valid, but unconfirmed transaction will eventually be included in the blockchain.

This isn't to say that you should never, ever accept a 0-conf payment. Perhaps you run a service where the risk of a double-spent payment is somewhat inconsequential to the way you make money. If a customer misbehaves, you cut them off, and thats the end of it. No major loss on your part.

But if your job is to sell very expensive rocket ships, you should probably wait for several confirmations before you allow your customer to blast off, in case they maliciously double-spend the payment to you, and get a sweet new rocket ship free of charge.

Does a lightweight wallet have the same security as a full node under this 0-conf scenario?

I think the reason that the attacks you listed are often mentioned is because the more important point is that '0-conf' transactions are inherently insecure, and those are the sorts of attacks that are the reason for this. It is of lesser importance whether your wallet/node can confirm just the validity of the transaction or not.

But to answer your question more directly, I think a lightweight wallet will have a difficult time figuring out whether a transaction is valid or not, without just validating all of the data itself locally anyways.