I do not think that a wrapped segwit version of P2PK would have been attractive regarding weight in comparison.
The wrapped segwit outputs work by putting the witness program in the P2SH-redeemscript in the input script and a hash of the redeemscript in the output script. In the case of a P2SH-P2WPK, a witness program in the style of P2SH-P2WPKH could perhaps have been <version> <pubkey>
(OP_CHECKSIG implied, like with the other segwit output constructions) and then just a signature instead of signature and public key in the witness stack.
A P2SH-P2WPKH redeemscript is 22 B long. The hypothetical P2SH-P2WPK redeemscript would work out to be 35 B instead—13 B more. On the other hand, the witness stack would have been 34 B shorter because the public key is not appearing there, but because of the witness discount, this only saves 8.5 vB.
So, P2SH-P2WPK would have been 21 B less data on the wire, but 4.5 vB more expensive for the receiver to spend.
P2TR now is a spiritual successor of P2PK: it locks funds directly to a key and only requires a signature to spend the funds. Since P2TR was packaged with the more compactly serialized Schnorr signatures, the reduced input weight can almost balance out the increased cost of storing the whole public key instead of a 20-byte hash. The combination with the Schnorr signatures made it a lot more attractive by simplifying key aggregation.
There was no wrapped variant of P2TR offered because 1) the P2SH-wrapper uses additional data increasing cost and blockspace footprint, 2) having only one output type leads to better privacy and homogeneity of transactions in the long term. The main reason to provide the wrapped variants when segwit came out was to provide forwards-compatibility for old wallets, so that they would be able to send to non-malleable segwit outputs immediately. Since many wallets can now send to bech32(m) addresses, this is no longer as pressing.