These 3 tables (pagelinks, templatelinks and imagelinks) do basically the same thing, and could be merged relatively easily. The only difference between them (aside from the prefix on the column names) is that imagelinks doesn't store the destination namespace because it doesn't need to.
Reasons for merging:
- Simpler, cleaner DB schema.
- A large amount of the code that references these (e.g. in Special:Whatlinkshere or BacklinkCache.php) is waaay more complicated than it needs to be - this would be mitigated if a single table were used.
- It is more future-proof - we can't keep adding a new table each time there is a new link type we want to report on.
- It would open the door for extensions to extend this functionality, e.g. if there are new types of links that they create.
The schema would basically be the same as for pagelinks, but with an additional 'linktype' column. This column would need to be defined such that extensions can add new types, which probably means VARCHAR.
With regards to point #4, I have a use-case for this. My WikiDB extension  adds database functionality to the wiki, such as tables (defined in a table namespace), <data> tags (which define the data that goes in them) and <repeat> tags (which are, effectively, queries). When viewing 'what links here' for the table definition, users would expect to see included any pages which display the table's data (via a <repeat> tag). The way to implement this in the extension would be to add the relevant entries into this new 'internallinks' table with a linktype of 'wikidb_data'. This, plus the relevant i18n messages (keyed to the linktype), would mean that the Special:Whatlinkshere page could not only show these links and mark them as 'data', but (probably with no extra work) the option to show/hide this type of link could be included in the toggle links at the top.
I think this is probably a technically simple change, with the challenge being around the migration path for existing wikis (especially the big ones!).
Note that I haven't included the various other link tables in this list (e.g. categorylinks). There is some overlap, but they seem to have different data requirements and use-cases, so are probably not candidates for merging.
 Theoretically at least. I am aware that the implications of migrating e.g. en.wikipedia might be prohibitive to actually making this change, but I hope it can be discussed a bit more thoughtfully rather than simply being shut down on those grounds.