Personally, in my Axeanoid program, there is 4 types of bricks (which are stored as 8x8 sprites at the beginning of the program) and the level is stored in an appvar. Said level is a tilemap, each type of brick is assigned a 4-bit number between 0x0 and 0xF. So in Axe, you would retrieve each brick using nib{} (instead of the normal {}) and do the correct conversion (displaying the correct sprite using the number from the tilemap). Useful if you have less than 16 sprites, it divides the size of your level by 2.

Also, could I get some guidance on when to use temp ram areas/external variables rather than portions of program memory for data storage?

There are certain chunks of memory in system RAM ($8000-$9D94) that programs can use for temporary storage:

• appBackUpScreen - 768 bytes, perfectly safe (L3 in Axe; it's used for the back-buffer, so don't use it if you use grayscale in your game)
• saveSScreen - 768 bytes, safe unless APD (auto-power-down) starts (L1 in Axe; last 54 bytes are used for A-Z and θ variables in Axe)
• tempSwapArea - 323 bytes, safe unless you archive/unarchive a variable (L4 in Axe)
• textShadow - 128 bytes, used to store the contents of the homescreen, so safe as long as you either:
  • not use the homescreen bcalls at all; or
  • run RES appTextSave,(IY+appFlags) before using any homescreen bcall
• statVars - 531 bytes, not to be used if running from MirageOS or using statistics functions (L2 in Axe; do not use in Axe if custom interrupts are enabled, either)
• plotSScreen - 768 bytes, safe if you don't draw any graphics, since this is used as the graph buffer (L6 in Axe)

There are more, but they get smaller (<100 bytes).

Generally, it's smaller to use scrap RAM for temporary variables, while constant data should be stored in the program itself.

Don't use them if the data is required for the program to run, though (always have a backup to rely on in-prgm). Appvars are generally useful for saving high scores or external levels.

If you only have a limited amount of data (0-768 bytes), you could probably use safe ram.  Also, if you want it to be modified, you should use safe ram when possible.  Also, any space you reserve in your program adds to the overall size, and should be avoided.  Large amounts of data can also be compressed, but will most likely have to be decompressed as well.  If you have large amounts of data to manipulate, you can consider swapping in a spare RAM page for tens of thousands of bytes, like I do in Motherload.  However, this restricts you from using many OS routines, and interrupts must be disabled.  Another alternative that is much less common is creating a temporary appvar or program to store information in during the program's lifetime.  However, you aren't always guaranteed to have enough space.
As for compression, there are several ways.  Run length encoding is one popular and simple way.  There are many others.  Both memory usage and compression algorithms should be appropriately used to suit whatever your specific needs are.

How does one use an appvar? I've never done anything with apps or appvars, so I'm kinda new to all this

Ah okay, thanks. What's the size limit for an appvar?

But when it's in Archive, wouldn't it only be accessible by an app and not by a regular asm program?