Can I increase readility of nftables ruleset syntax and does it affect its function?

To verify two rules are identical even beyond being displayed the same (in rare cases involving multiple protocol layers, rules can display the same, be functionally equivalent but not be exactly the same at the bytecode level, that's almost a reproducibility bug), use the option --debug=netlink which will also display bytecode sent to the kernel. If the bytecode is identical, the rules are identical.

Here's an interactive example (using nftables 1.0.9. Results can slightly change depending on version):

$ unshare -Urnm
# nft -V
nftables v1.0.9 (Old Doc Yak #3)
  cli:      editline
  json:     yes
  minigmp:  no
  libxtables:   yes
# nft add table t
# nft add chain t c
# nft --debug=netlink add rule t c 'meta skuid == "root" counter accept'
ip t c
  [ meta load skuid => reg 1 ]
  [ cmp eq reg 1 0x00000000 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 accept ]

# nft --debug=netlink add rule t c 'skuid 0 counter accept'
ip t c
  [ meta load skuid => reg 1 ]
  [ cmp eq reg 1 0x00000000 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 accept ]

# nft --debug=netlink add rule t c 'ct state == { established,  related } counter accept'
__set%d t 3 size 2
__set%d t 0
    element 00000002  : 0 [end] element 00000004  : 0 [end]
ip t c
  [ ct load state => reg 1 ]
  [ lookup reg 1 set __set%d ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 accept ]

# nft --debug=netlink add rule t c 'ct state established,related counter accept'
ip t c
  [ ct load state => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x00000006 ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 accept ]

As can be seen the 2 first rules are the same. Indeed "root" is resolved as usual to the uid 0 by userspace, and the meta keyword is optional (at least with the version here).

The two last rules, even if functionally equivalent, aren't identical. On case uses an anonymous set of two values. But these two values are meant to be combined in a bitwise manner (ie: all possible symbols have different exponent of 2 as value), that's what is doing the last rule instead where the , takes a different role. At a glance, I'd tell the 2nd ct rule is more optimized than the first: no need to involve a set lookup.

Still use of the first case exist: when using vmap (a verdict map rather than a simple set) to call different verdicts depending on the conntrack state in a single rule.

Whatever you choose, for a given nftables version, it will always be displayed back in one way:

# nft -s list ruleset
table ip t {
    chain c {
        meta skuid 0 counter accept
        meta skuid 0 counter accept
        ct state { established, related } counter accept
        ct state established,related counter accept
    }
}
# 

That should probably be what to use, or that might anyway end up being used, just because when handled manually rather than by tools it's often practical to dump the ruleset, edit it, and reload it.

The case in ct cannot be generalized at all: the 2nd variant can be done (if specific syntax support is implemented anyway) only where power of two values are involved so they can be combined in bitwise operations:

# nft describe ct state
ct expression, datatype ct_state (conntrack state) (basetype bitmask, integer), 32 bits

pre-defined symbolic constants (in hexadecimal):
    invalid                         0x00000001
    new                             0x00000008
    established                     0x00000002
    related                         0x00000004
    untracked                       0x00000040
# 

An obvious example is the use of the TCP flags with nftables:

# nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

pre-defined symbolic constants (in hexadecimal):
    fin                             0x01
    syn                             0x02
    rst                             0x04
    psh                             0x08
    ack                             0x10
    urg                             0x20
    ecn                             0x40
    cwr                             0x80
# 

So just like ct:

# nft --debug=netlink add rule t c 'tcp flags { ack,syn } accept'
__set%d t 3 size 2
__set%d t 0
    element 00000010  : 0 [end] element 00000002  : 0 [end]
ip t c
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000006 ]
  [ payload load 1b @ transport header + 13 => reg 1 ]
  [ lookup reg 1 set __set%d ]
  [ immediate reg 0 accept ]

# nft --debug=netlink add rule t c 'tcp flags ack,syn accept'
ip t c
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000006 ]
  [ payload load 1b @ transport header + 13 => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x00000012 ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]
  [ immediate reg 0 accept ]

# nft --debug=netlink add rule t c 'tcp flags ack|syn accept'
ip t c
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000006 ]
  [ payload load 1b @ transport header + 13 => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x00000012 ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]
  [ immediate reg 0 accept ]

# 

The two last rules (note the use of | for a bitwise OR operation instead of , for the built-in syntax) are exactly the same. But first rule uses an anonymous set just like in the previous case. In all cases in this example, one matching TCP flag among multiple is enough to match: functionally equivalent. Had there been the need to match two flags at once, only the 2nd case would have been usable.

Typically the rule below, that requires the presence of two flags at once, cannot be implemented with an anonymous set:

# nft --debug=netlink add rule t c 'tcp flags & (syn|ack) == syn|ack accept'
ip t c
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000006 ]
  [ payload load 1b @ transport header + 13 => reg 1 ]
  [ bitwise reg 1 = ( reg 1 & 0x00000012 ) ^ 0x00000000 ]
  [ cmp eq reg 1 0x00000012 ]
  [ immediate reg 0 accept ]


# nft list ruleset
[...]
        tcp flags syn,ack / syn,ack accept
[...]

Note: it doesn't make sense to combine in this manner flags with ct because contrary to TCP flags, only one flag at once is supposed to exist (a given packet can not have multiple conntrack states at once).