As a general design pattern, manifests are useful when you want to collect all the information about a disparate set of objects into a single place. It doesn't have to be about archive/packed files, or about indirection to allow things to be moved without recompiling/updating original references. Indeed the latter can introduce more problems than it solves, so you would only do that if it solved a particular need you had.
The big advantage of manifests is that they act as an index to a large amount of data in a single compact place. As such they improve performance (because you can simply load the entire manifest from disc and keep it in memory), especially in the case where you need to iterate over multiple objects, but you don't know in advance what those objects will be. If the objects are on disc, especially if they are in multiple places, you have to touch the filesystem every time you want to iterate over files. For disc-based file systems, the time needed to touch the filesystem is prohibitive, so iterating over files in a directory is a massive cost. By pre-building a manifest of files at build time (NB: not compile time), you trade that cost for memory usage.
Archive files require the use of manifests, simply because the table-of-contents for the archive is essentially a manifest itself, so you get the behaviour for free. And if you are required to use manifests for assets in one location, it can be cleaner to insist that all assets be referenced through manifests; allowing you to abstract the actual storage location/mechanism of the assets from the references to those assets in code. That way you can have a single asset reference type in your code, and not have to make the distinction between file paths, archive file path + offset, or sub-assets.