The thin line for the palm tree would be its base rect, which extends all the way from the bottom left of its cel to the bottom right. The thickness is determined by the object's yStep. Whenever a View is initialized or positioned, it calls the BaseSetter kernel, and that's what sets the View's brTop et al properties.
Now, Views always use the BaseSetter kernel, but Actors have a baseSetter property -- if you attach a Code object to that, it'll call doit on that Code, passing a reference to itself, so you can make the palm tree use a smaller base rectangle. Of course, to use an Actor for a non-animated element like a palm tree might be overkill so perhaps providing your own init might work better. First call (super init:), then set your own base rect right after. That might work well enough.
The ignrAct status bit ($4000) has these effects, among others:
1. When using addToPic, any view not ignoring other actors has its base rect rendered into the control map.
2. CantBeHere will, as the names suggest, skip checking other actors' base rects when determining if a View with ignrAct set can be there or not.
So its relevance here seems a bit off.
Why the Zodiac appears like that, I dunno.
As for view resource limitations, there's the general resource size limit. I'm not sure how well dither patterns RLE compress -- it depends on whether they're by pixel or by color, so that's a consideration and a half.