Hi,
The SAP auth concept and role mechanisms aren't perfect but they are what we are given.
The scenario you have described is one way of doing it but tasks combined in composites is not the only standard approach. Derived roles offer some benefits but also have drawbacks and are not the default answer and as you have found, there is no point in using master & derived if the derived roles have different object values from the master.
Some of the risks I see are:
1. Reduced supportability - using standard mechanisms makes it easier for other people with standard security knowledge to support the design.
2. Less likely to get bitten by future SAP developments - It is very unlikely that SAP would intentionally break their standard concept.
3. Upgradeability - All sorts of weird and (not very) wonderful things can happen to non-standard auth concepts when upgrading. Usually the architects of the solution are long gone at this point.
4. Reduced usability with SAP tools - there are some exotic role designs in the wild that require workarounds to work well with GRC or IdM (although IdM can adapt to these quite easily with some clever rules and/or creation of additional master data).
Cheers