So I find that organizing my code with data structures and functions adds a lot to the runtime cost in PICO-8.

For example, doing vector math with objects like {x=1,y=2}, and functions like

function vadd(v1,v2)
  return {x=v1.x+v2.x,y=v1.y+v2.y}
end

greatly increases the readability of my code, but at the cost of significant performance hit.

Coming from a C++ background, this really upsets me. Modern C++ compilers are extremely good at optimising, and it's often possible to write very expressive code with almost zero overhead. While in PICO-8, if I want my code to go fast, I have to write it in a rather repetitive and messy way.

I like how PICO-8 is deliberately restrictive, but is there a way to write clean code without hurting performance too much? What are your thoughts?

Pico simulates a 80-area console/computer.
(and actually many pico ops are cheap, like divide or table access!)
Op costs are a bit awkward sometimes but that is part of the package.
And you still can do a lot ;)

What Fred said.

It seems to be meant to be a fun little retro programming experience, the kind people had when they actually bought computers like C64s back in the 80's, where when you turned the machine on, you were immediately at BASIC interpreter prompt—except this time it's Lua and the prompt is complemented by a few nice editors.

I think the process for a lot of people who pick up PICO-8 is like this:

• I want to (learn to) write simple little retro games
• oh, this is nice, everything is so direct and simple and (as zep says) cozy
• wow I'm actually able to write games now
• I wonder what I could make this little platform do!
• hey everybody look what I squeezed out of PICO-8!
• the code to do that was gross though; let's make it more stylish and elegant!
• oh, that added a lot of overhead on the throttled virtual CPU
• maybe I should try something closer to native code, like Löve2D or monogame...?
• hey everyone, check out the xyzplatform version of my game, it's even bigger and better than the PICO-8 prototype! *cough*Celeste*cough*

Add a few more steps after that where some people then move on to writing even bigger games in engines like UE or Unity.

I suspect you're simply at the "oh, that added a lot of overhead" stage. If you're already a game programmer in C/C++, then obviously the earlier stages don't apply to you, but that one still will.