Chaitanya Donthini I am thinking of IT Pro and Help Desk Scenarios where those parameters are not as easily known (yes, they can find out the AppID field but they don't generally want to deal with locating the XML.
If someone does work to improve this cmdlet, in addition to removing restrictions, it seems like either PackageFamilyName OR AppID OR ProcessID of processes running in the environment should be sufficient to specify. I was looking at one of the SDKs yesterday that seemed to want the ProcessId (or handle to it) to gather the package details of the others. Sometimes, but not always, process name might be useful as ProcessID can be found from that (as long as only one copy is running). Cmdlets like Get-Process and Get-AppVVirtualProcess come to mind as examples. Also the Package Name (the one without the hashed PublisherID) would be a better choice than PackageFamilyName.
But if there were two copies of the app package running in different containers (a scenario we hope to see at some point) we'd need to be able to specify which one to inject the new process into, and ProcessID is a convenient way to specify it. Certainly in an RDSH/RDMI situation today we'd need to target the package running in a certain user session anyway.
I'd also say that the online help for that cmdlet needs some love. There are lots of placeholders like {{Fill in the Description}} everywhere in the help. PrevertBreakAway and Examples have placeholders and are not obvious..