Hello
Yes, there are alternative strategies. I am not keen on multiple central repositories (across the landscapes), they introduce too much complexity and really aren't required. Consider a software company, they use a single repository for their releases, why should Data Services code be any different?
A single central repository under the development environment is all that's required, with a responsible person to build and label releases. A local repository in the development environment is used to assemble release candidates (using the central repo); package it with other artifacts (SQL, etc.) then pass this to other environments, first QA, then if it passes testing, the release can go to production.
The Data Services documentation has unfortunately given people ideas that are too complex for moving code across environments.
As for system and datastore profiles, they are intended to allow jobs to be executed against various sources and targets (for example load US, then UK sources into a common target), not to cross the system landscape. I mean, what sort of organisation would put production credentials anywhere other than production?! (Although they can be useful in non-prod to load data across the landscape, QA into dev for error diagnosis.
Setting up robust procedures is not easy, but it does help for an easy life in the future.
Michael