I know I'm going to get flack for this, but it is a forum. Please assume that I know the benefits of scheduling everything you can in SQL Agent, there is plenty to be said for keeping it simple. I have also bumped into the problem of delegating job owners and editors to pretty much the same conclusion in several different environments. In most cases, adding the trustworthy users to the TargetServersRole role was enough to get by, but it never solved the problem completely. So that being said, I have a tirade to go along with this.
/* Begin Tirade */
To answer your actual question, no, I am not satisfied with the way SQL Server Agent works, but honestly, if it worked the way I wanted it to, it would be a separate product with a SQL backend divorced from the DB engine.
If "SQL Server Agent" were meant for developers it should have been called "SQL Server Developer Agent" or "Microsoft Enterprise Scheduler" It's my contention that SQL Server is not meant to be a scheduler for jobs that the DBA isn't responsible for or that don't directly affect the health and maintenance of SQL Server with very few exceptions. SQL Server Agent falls short of an actual enterprise class scheduler for several reasons. There are other reasons, but these are my top 5.
1) All jobs execute locally on the node hosting the SQL instance, this robs the node of resources that are used to service SQL.
2) Job coordination is limited to time, frequency, CPU idle and service start ... NOT inter-job dependency or extra-server signals. I know there are people out there who say you can create inter-job dependency by having one job spawn another, but try to have one job dependent on the completion of two others without creating schema or logic to support this.
3) Job notification relies on custom dbmail scripting or arduous operator setup which fall just outside of the DBAs core responsibilities (I really hate adding and removing recipients to notifications of custom jobs).
4) Error logging, and the sometimes the full text of the job output is truncated due to limitations in the space allocated to agent logging - finding failure messages is hard, and sometimes not possible. This causes lag between problem and resolution because the responsible parties don't have access to all the information without a lot of additional work.
5) And, the reason this post was written, security and ownership of jobs becomes too complex too quickly.
Unless you have a small shop, can fully trust non-dbas managing job schedules, operators, steps, and execution on the company's DATA STORE (not app server, or scheduler), or just have no other way of doing things, I would strongly recommend removing non-server related jobs from the production SQL instance and put them in an external scheduling environment where users can run amuck.
Options for your developers could be:
1) A SQL Instance dedicated to running jobs if you MUST use SQL Agent.
2) Use an actual enterprise scheduling software (they do exist, wikipedia has a good list of job scheduler softwares).
3) God forbid, use task scheduler (primitive, but it works)
4) They're devs, heck they could build their own
/* End Tirade */