Nope, one would normally write the code which parses such S-expressions such that the first atom in each list indicates the function to use to parse the rest of the list. So there'd be a FEED-FEED function which knows that a feed may have version, homepage URL &c., and there'd be a FEED-ITEMS function which expects the rest of its list to be items, a FEED-ITEMS-ITEM function which knows about the permissible components of an item &c.
If you really want to do a hash table, you could represent it as an alist:
(things
(key1 val1)
(key2 val2))
This all works because — whether using JSON, S-expressions or XML — ultimately you need something which can make sense of the parsed data structure. Even using JSON, nothing prevents a client submitting a feed with, say, a homepage URL of {"this": "was a mistake"}; just parsing it as JSON is insufficient to determine if it's valid. Likewise, an S-expression parser can render the example, but it still needs to be validated. One nice advantage of the S-expression example is that there's an obvious place to put all the validation, and an obvious way to turn the parsed S-expression into a valid object.