Baked lighting computes bounced light offline and stores it in textures. It is cheap at runtime and rigid — and it puts a specific requirement on your meshes.
The second UV channel
A lightmap needs its own UV layout, separate from the texture layout, with one crucial difference: no overlapping islands. Texture UVs frequently overlap deliberately to save space, mirroring one half of a symmetrical object onto the other. A lightmap cannot do that, because the two halves receive different light.
So a baked asset carries two layouts: UV0 for textures, UV1 for lightmaps.
Generating versus authoring
Engines will generate lightmap UVs on import, and the results are usually acceptable for props and mediocre for large architectural pieces. Hand-authored lightmap UVs — with generous padding and consistent density — are worth it for anything large or prominent.
Resolution
Lightmap resolution is per-object and it is where baked lighting's memory goes. A large wall needs more texels than a small crate to reach the same visual density, and getting this wrong shows as blocky shadows or as wasted memory.
What cannot be baked
Anything that moves. Baked light is static by definition, so dynamic objects need a separate solution — light probes, which sample the baked lighting at points in space and apply it approximately to moving objects.
Baked versus dynamic today
Dynamic global illumination (Lumen, and equivalents) removes the bake step and the lightmap UVs entirely, at real runtime cost. Projects targeting high-end hardware increasingly go dynamic; projects targeting mobile, VR or a wide device range still bake.
Both remain current. This is not a case of one superseding the other.