The manifest-import service manages importing of manifests that are delivered as part of a package for an application. This instantiates the service and its instances on the system. The manifest-import service will then manage re-importing those manifests if they are modified/upgraded in some way.
Also, the manifest-import service manages the application of profiles that are in the standard location for profiles of /etc/svc/profile/site. If these profiles change or are removed then the support for them can be removed from the services on the system.
Finally once the application has served its purpose and the delivering package is removed from the system along with the removal of the manifest the service will then be cleaned up by the manifest-import service.
With that the manifest-import service needs a well known place to be able to find the manifests for a service, and be able to find those manifests under a certain set of rules. One, the cleanup side of the service needs to be able to know for sure that a manifest is removed and not that a location is simply temporarily unavailable.
Before the Solaris 11, the manifests were located in /var/svc/manifest. But this location might or might not be available at boot because /var can be a separate filesystem, that is not mounted early in boot. With the Solaris 11, the manifests were moved to /lib/svc/manifest so that the manifests would be available at the beginning of system boot. Therefore, manifests are to no longer be placed in /var/svc/manifest as it is strictly supported for backwards compatibility only.
So with this standard location that is guaranteed to be available at boot SMF can now make sure that changes and upgrades to manifests are imported before any services are started. This way services that need to start early in the boot cycle (even before /var might be mounted, if the manifest is in /lib/svc/manifest) will be guaranteed to start with their new property values.
Also, if the manifest is removed from the system, there is a chance for the service to be removed from the system before it attempts to start and does not find the service binaries and/or other files that may be required for the service to run.
Put your manifests and profiles in the standard location and let SMF manage your import, apply and ultimately the cleanup of your services and instances.
So in summary the benefits are :
1. manifests can be imported early in boot before any services are started that might use the information from the manifests.
2. upgrades of manifests and profiles can be done during this early boot phase as well, so that services get the new information before they start.
3. if manifests are removed, then the manifest-import service that manages these can know for sure that the manifests are removed and clean up the services.
4. manifests in a standard location are the base layer for services and their property group and property sets.