Konstantin,
I too was a bit surprised by Anirban's initial question, but I think I get it now.
Just to add a bit on the 'motivation' for doing this sort of thing: At Medtronic, when we extend the configuration of ME by adding attributes to core objects (eg: custom data to Materials, system rules to Sites, etc), we try to use the core facilities. We don't want to fragment and scatter our configuration user interfaces. As a Medtronic ME user, if you want to configure a Site in ME, you (usually) go to System Rule Maintenance. We carefully control access to System Rule Maintenance.
If we were to create another table (or set of tables) in the database to hold this new configuration data, we would then create a configuration UI for that, and that UI would have to have rights associated with it. Also, we would generally add audit-trail functionality. Quite a bit of stuff to maintain going forward. We can't avoid this if we're creating a brand new class of objects, but we can if we are just extending existing objects.
The code that 'consumes' (reads) the values of these custom configuration attributes might be custom ME activities written in Java, custom BLS's created in MII, custom reports (in BO), or maybe even custom stored procedure code in Oracle.
Given our experiences so far with ME SDK coding, I think there's a general desire to move towards using MII more. (Personally, I'm not sure that I agree, but I don't make those decisions.)
Still (back to Anirban's original question), we won't get away from SDK coding anytime soon, so I don't see a good reason to avoid using an IDAT in this particular case.
Regards,
Barry