Security best practices for SSIS package execution via SQL Agent job
You don't need to use a proxy account nor do you need to grant sysadmin to your ETL team for them to be able to run SSIS packages and SQL Agent jobs.
You should first look into the SQL Server Agent Fixed Database Roles, such as the SQLAgentOperatorRole. (I'm guessing you have already, but in case you haven't yet.)
If that alone doesn't solve your issue then you should also look into Integration Services Roles (SSIS Service) - Roles in the msdb database. If you need the ETL team to be able to execute SSIS packages that they don't own, then you'll want to particularly look into the db_ssisoperator role or db_ssisadmin role which are certainly more limited than sysadmin. (It sounds like db_ssisoperator is probably what you want.)
One caveat with the db_ssisadmin role is it has the ability to run an SSIS package that can execute the T-SQL to grant the sysadmin role to a user (if the package runs under an existing sysadmin account), should someone on your team feel maleficent enough to create such a package and run it, as mentioned in this warning:

**** Warning ****Members of the db_ssisadmin role and the dc_admin role may be able to elevate their privileges to sysadmin. This elevation of privilege can occur because these roles can modify Integration Services packages and Integration Services packages can be executed by SQL Server using the sysadmin security context of SQL Server Agent.

If you only need your ETL team to be able to run only their own packages, then the above warning is moot, because you can use the db_ssisltduser role instead.