Trying to generate an Ethereum address from the public key, I got this very accurate answer:
... (address) must be generated on the basis of the uncompressed key (0x04|x|y). The leading marker byte has to be removed, from the rest, i.e. the 32 bytes x coordinate and the 32 bytes y coordinate, the Keccak-256 hash is generated, the last 20 bytes of which are the address.
And this code is the proof, you can check it here:
const { secp256k1 } = require("ethereum-cryptography/secp256k1");
const { keccak256 } = require("ethereum-cryptography/keccak");
const { toHex } = require("ethereum-cryptography/utils");
const { encode: checksum } = require('eip55');
const privateKey = secp256k1.utils.randomPrivateKey();
console.log('private key : ', toHex(privateKey));
// you need to ask for the uncompressed public key
// (note the 'false' as the second parameter)
const publicKey = secp256k1.getPublicKey(privateKey, false);
console.log('public key :', toHex(publicKey));
const address = keccak256(publicKey.slice(1)).slice(-20);
console.log('address :', checksum('0x' + toHex(address)));
But if the compressed public keys are now the default and preferred over the uncompressed version, why are the addresses still generated from the uncompressed public keys? This confusion is even present in the documentation, without giving a clear answer (although related to Bitcoin, it's also relevant to Ethereum):
(...) if we convert this compressed public key to a commitment (...), it will produce a different commitment than the uncompressed public key, leading to a different address. This can be confusing because it means that a single private key can produce a public key expressed in two different formats (compressed and uncompressed) that produce two different Bitcoin addresses. However, the private key is identical for both Bitcoin addresses.