When you use DropDMG to create a tar archive, it should copy all the metadata that’s supported by the tar format, which I think is everything except the Finder locked flag.
When creating a device image from a read-only volume, DropDMG will preserve everything, including the inodes.
When creating a disk image from a file or folder, DropDMG relies on Apple’s hdiutil and ditto tools. At present, these copy the ownership, permissions, Finder flags, modification and creation dates, Finder comments, and resource forks. (In order to preserve the owners when restoring, you’ll need to mount the image with DropDMG rather than the Finder.) The BSD flags, symlink ownership, Finder locked flag, and extended attributes are not copied. However, in general I don’t think this is a cause for concern; if you need that particular metadata, you’ll probably know that you need it.
I would like for DropDMG to preserve all the metadata, as that removes any guesswork. However, there are tradeoffs. Because of the lack of support in the underlying Apple tools, creating an image with DropDMG would take roughly twice as long and require roughly three times as much temporary disk space in order to preserve all the metadata. My guess is that for most people this is simply not worth it, and I believe you are only the second person to even ask whether DropDMG preserves extended attributes.
My plan for future versions of DropDMG is to add support for creating device images from read-write volumes; this would allow you to create a full backup of an entire drive, preserving everything. For file/folder images, I will probably add an option so that those who don’t mind the speed and disk usage tradeoff can opt to preserve all the metadata.