I don't know of any specific reason, other than I guess that it wasn't a requirement at the time it was implemented the way it is.
As a feature I think it would be great, and we actually gave it some thought as to if we could implement something like this for Totara, but it is hard to see a path to making such a fundamental change to the existing code.
For example, I suspect it would break moodle's hierarchical capabilities system. If you have a forum activity for example, in mdl_forum:
And you put the same instance in two courses via mdl_course_modules:
| id |
course |
module |
instance |
| 1 |
2 |
11 |
1 |
| 2 |
2 |
11 |
1 |
Then the context table will need to look like this:
| id |
contextlevel |
instanceid |
path |
|
| 1 |
10 |
0 |
/1 |
Site context |
| 2 |
50 |
1 |
/1/2 |
Site course |
| 3 |
40 |
1 |
/1/3 |
Miscellaneous category |
| ... |
|
|
|
|
| 23 |
50 |
2 |
/1/3/23 |
Our first course |
| 24 |
70 |
1 |
/1/3/23/24 |
Our forum activity in course 1 |
| .. |
|
|
|
|
| 47 |
50 |
3 |
/1/3/47 |
Our second course |
| 48 |
70 |
1 |
/1/3/47/48 |
Our forum activity in course 2 |
| ... |
|
|
|
|
So now any changes to activity level capabilities are no longer stored in one place, plus you need to figure out which courses contain the activity so you can rebuild the cache, and before you know it you have to rewritten accesslib.php 
.
You can see how a single modified assumption (one course module record per instance) can lead to further changes to other assumptions (one context per instance), which then leads to more changes...
So yes, something for Moodle 3.x I suspect.
Simon