By way of expectation management, historically Tinderbox has centred on textual analysis - in part because back in 2000 images (in this sort of context) were less easy to work with.
Size. Any image stored in note text ($Text) or as a map image adornment will add to document size. As a TBX is stored as XML, the images need to be stored as Base64 (binary data encoded as text) so reversing the compression factor of some image formats. This chimes with the point above re text vs images.
I’m less sure as to how image size affects app performance. However, common sense dictates using as low res a version of a source image as possible. This isn’t an image manager and isn’t going to thumbnail for you (in case that was your expectation).
Images placed in note $Text can be viewed in map icons as part of displayed text. Images can also be viewed in Hover Expressions. I think pushing hard on either of these may likely have you pushing into ‘new feature request’ territory.
Also consider the approach of using ‘fills’ which were originally intended as a way of drawing a textures on the face on map icons. Note: these assets are stored externally (though that does meant they need to be on all Macs you use to edit/view the TBX). A fill is probably as close as you can get ,visually, to a an image adornment whilst still being a note.
I’d also recommend looking at Howard Oakley’s blog. Although he uses Tinderbox’s sister program Storyspace, in the above context they are essentially similar (using the same code base underneath). Howard has a number of articles were he discussed issue of using images in the app.