I often find myself declaring a lot of arrays/object literals that are essentially just data. No computation involved.
For example:

-- background types
bg_tree={
 tex={
  {sx=0,sy=64,sw=32,sh=32}
 }, 
 w=2,h=2,
 spacing=2
}
bg_lamp={
 tex={
  {sx=0,sy=32,sw=16,sh=8}
 }, 
 w=.5,h=.25,
 spacing=2,
 trans=12
}

It's a useful way to create flexible, extendable systems.

Unfortunately it quickly chews through the token count.

So I was wondering what people's views were of changing the token counting rules around such object literals? - say 1 token per object literal.

They would have to be restricted in order to qualify for a reduced token count, i.e. data only, no computation, functions etc, similar to how JSON is a restricted subset of JavaScript.
The compiler could either detect this automatically, or possibly a new "data only literal" syntax could be introduced.

I feel like this probably aligns with the PICO-8 principals, as it's arguably data rather than code, and you still have the compressed size limit. It seems like a much cleaner solution than the string shredding/JSON parsing workarounds that are currently used.

I understand the appeal of this suggestion, but I don't like it.

Tokens were introduced to be the main code limit unless you were doing something weird, so you could use longer identifiers and better structured code without worrying as much about the added text size. Huge amounts of data are possible with strings as a side effect of this, but it's not an encouraged behavior, because the 64KB uncompressed text size and 2MB Lua RAM cache are supposed to be invisible to most cartridge creators. I'd call larger carts an "advanced usage"/exploit of the existing systems, so I think it shouldn't be easy for newcomers to do this until they understand how all of these hidden constraints work together.

As an alternative suggestion, I'd like a way to convert saved data to and from cartridge RAM and Lua RAM, in some defined binary stream format that handles ints / strings / nested tables / functions / bools / etc. Right now there's no easy way to save and load Lua strings or objects in cartdata, as it's only accessed with 64 numbers via dset/dget, or peek/poke @ 0x5e00. And this feature would mostly solve your problem at the same time, because you could do something like this when exporting a cart that exceeds the data limit:

table = {whatever={...},...}
len = luaset(0x0,table) --data contains the length at 0x0, returns total space used to store
if(len<=0x4300) cstore(0x0,0x0,len)

--then replace that code with this before exporting:
table = luaget(0x0) --length is stored automatically at the start of the data stream

I like this idea better, because it still imposes a real ~17KB limit to your data and takes space away from the cartridge, but improves your token count in a standardized way. It also lets you copy an arbitrary table to cartdata, so you can save and load complex games more easily.