Rauf,
I would add to your possible solutions slightly, but here is my modified summary:
Storing the alternate account number
1- Continue with your original plan to use OBJA and SUBA, if your alternate account number fits into the BU.OBJ.SUB model. That leaves that 3rd Acct No field open for a future acquisition/integration/etc.
2- If not, use the 3rd Acct No to store the complete alternate account number as you noted.
Storing the description for the alternate account number - (Ideally you would be using the same description as the primary account number since, for example, AR Trade should be the same regardless of the identifier. However if that doesn't meet your requirements):
1- Put the description for the alternate account number into a new Supplemental Database (F00092). The advantage to this is there is no custom coding - only configuration. The disadvantage is that it can get a bit clunky for the user to enter data, unless you have CAFE1 layouts available. I can't recall whether CAFE1 is available in your release.
2-If using the Supplemental Database is not feasible, create a tag file with AID as a reference as you noted.