You could avoid the extraction process by using the following Powershell:
Add-Type -AssemblyName "System.IO.Compression.FileSystem"
This could be combined with your current custom script which is checking the files, or you could add this to a Run a Script step with the package referenced, but not extracted.
However, this would still transfer the package to the target. If the files don’t meet your criteria, you could fail that step and then have a subsequent step to run only when the previous step fails or on a variable you set which could then delete that package from the target, or just let the retention policy clean it up.
If you are wanting to avoid the transfer altogether, you might be able to handle that with channels and versioning rules so that the same SQL package versions get deployed with the right application version. This, of course, depends on how you have things set up. Another possibility might be to have your build server enforce the creation of releases so that it can pair up the correct application package with the SQL package.
As far as evaluating a package in a release without transferring it anywhere, the closest you could get would be to use a worker (which might be the built-in worker). This would keep it off the target but suffers from the fact that if it is the desired package it will need to go through 2 package acquisition steps.
I hope this helps!