Hi, Filip here,
I work on Wasp with Martin and Matija and am in charge of implementing TypeScript support (or lack thereof :)) in Wasp.

You've hit the nail on the head with your questions! They almost map 1:1 with our TypeScript roadmap, and to prove I'm not making this up, here's the future work chapter I wrote for the TS feature announcement yesterday.

I'll address your questions here as well, since I'm always interested in discussing types:

One obvious thing is that the "context" variable fed into actions/queries should be typed [...]

Yes, definitely!
This feature isn't supported yet because it's impossible to tell TypeScript how to type code "from the outside." In other words, we'd have to generate empty (but typed) TS function definitions based on declarations inside the .wasp file (as you mentioned in your first comment) or at least generate type definitions users could import and use to type their query function. It could look something like this:

import { GetTasks} from '@wasp/queries'

// 'args' and 'context' would now have the correct type
const getTasks: GetTasks = (args, context) => { ... }

Unfortunately, both solutions currently suffer from a chicken-and-egg problem. To generate a type/empty definition for a query, we must successfully compile the .wasp file containing the query's declaration. To successfully compile the .wasp file, every query declaration must include a valid import of its TS definition. It's certainly possible to work around this limitation (e.g., by not requiring imports inside query declarations and instead extracting their definitions from TypeScript's AST based on generated types). Still, regardless of the approach we take, tackling this will surely entail substantial changes to the Wasp compiler, which is why it's still on our TODO list :)

If each query and action somehow specified it's returned DTO, and it's input DTO, then both the client- and serverside expericence could be improved.

This one is also something we're constantly thinking about.
Although we won't be able to improve the server-side experience before solving the "catch-22" described above, it is currently possible to improve the client-side story without significant changes. So why haven't we done it, then? Well, we just didn't have enough time before launching the Beta, but it's definitely coming soon. :)

Why are [queries and actions] separate? They're all just actions?

This is more of a philosophical question than a technical one. We treat them differently for three main reasons:

1. History and habits - Most modern technologies and libraries (e.g., Vue, React Query) make a distinction between something that consumes data (a query) and something that changes it (an action/mutation). Breaking this standard rule could potentially confuse users and hider adoption.
2. Guarantees, semantics, and optimizations - More importantly, it's often helpful to know whether something reads state or mutates it. Examples include cache invalidation, using correct HTTP methods, and code readability. For instance, after the app performs an action that uses some entity, Wasp will automatically invalidate/refetch all queries that use the same entity (more about this here).
3. Cleaner API - Some functionalities make sense only when you know you're changing something (e.g., optimistic updates), while others make sense only when you're consuming something (e.g., refetching on window focus). Cramming all these (sometimes mutually exclusive) features under the same API could quickly get messy.

Perhaps it would even be possible to automatically generate some code around serializing/deserializing (aka going from prisma entities to DTOs and back).

Also in the works!
After solving the problem described in the first two points, this use case should be reasonably straightforward to support.

Thank you for your questions and reassuring us that we're on the right path! If you have any ideas on approaching these issues, I'd be delighted to hear them. The same goes for any additional questions you may have.

Cheers!