I was thinking about how I could tackle compression in my game using 2x2 metatiles, and before writing my own command-line tool, I was wondering if it’s already possible to do this with NEXXT.

I’ve played around a bit with the Metatile window and managed to create some metatiles, but I’m still a bit confused about how to actually use them.

A parser/exporter tool to compress maps using metatiles as a dictionary is planned for for v4.x, but it's as of now not available. 
Since there's quite a broad range of popular options people will want to compress their maps in, this might take some time. 
Some people have written their own parsers in the meantime, which is simpler when you only have to consider one game's expected input. 

Metatile sets are stored as text, either in the .nss file, or as separately savable .mtt / mt2 / mt4 / mt8 files. This makes them a bit easier to parse. 
.mtt indicates a set of any and all sizes, while the 2,4,8 indicates it contains just one kind of metatile. 

Some usage tips:
-nexxt can automatically generate metatile sets from existing screen/map content. Press Rebuild (warning: this will overwrite existing metatiles). 
-look for the clonestamp label; press the 'on' button. this will replace the normal tile placement tool with a clonestamp / metatile placement tool. 
Normally, you'll want 'snap' to be on as well, unless you want to place metatiles off-grid and then Generate a new set out of those placements. 
-right clicking a metatile on the set canvas will find and step through matches on the map. I often use this to compare and clean up; replacing one instance with another, if i have to make the set smaller. 
-Under the hood, nexxt has no concept of a 'metatiled map'. This means you can move freely between tile and metatile placing without needing to convert to some other format, and you can even mix and match different metatile sizes for placement (hence the clonestamp terminology as far as placement is concerned). This is handy when constructing maps/levels, but it also presumes checking that your map matches a dictionary of metatiles at build time if you want to implement metatile compression. NEXXT is still lacking some would-be helpful functionality in that end step. 

I saw you mentioned RLE in the title. While there are circumstances where RLE on the NES can be useful, on maps it often quickly becomes more trouble than it's worth for slightly more ambitious projects, or things like scrolling/multiscreen levels, due to the limited cpu headroom for unpacking levels on the go. The exact threshold where it stops being helpful depends heavily on the game's design. Just thought i should leave a heads-up.

Using just metatile/dictionary compression is usually enough compression; while retaining random access, and stable cpu/mem footprint. 
Games that need to pack an extra lot into extra little sometimes do 2-factor dictionary compression, ie compress say 4 metatiles that commonly go together as a new keyword (sometimes refered to as a meta-metatile in the NESdev community),  but if you can avoid it it'll both be more performant and easier to complete. 

I appreciate your approach and the heads-up. I wasn’t sure myself how feasible it would be to implement column loading with a lookup table to track column boundaries under RLE compression. Coming from a frontend background, these concepts are still pretty new to me.

I’ll definitely keep your suggestion in mind about using metatiles for compression. It sounds much easier to maintain and navigate.

Thanks as always for your fast and thorough response.