You're not missing anything. Algebraic effects are basically typed gotos†[1][2], and are generally a bad idea to use and/or implement. They can be useful in a few very niche situations when using typed functional languages.
The big difference here is to understand the program with Algebraic effects you now need to know _where the code was called from_.
If you ask for an effect to come from higher up the call stack, does that mean part of the function signature needs to include that the call stack must be able to handle the effect?
And if that's part of the call stack, why not just make that an explicit function?
> Does that mean part of the function signature needs to include that the call stack must be able to handle the effect?
Some people would argue that the effects a function may raise are indeed a part of a function's type and for it to type check it must be within scope of a handler for that effect. Think of it like function coloring, a function with the "async/await" effect means all callees must be invoked either within an "async" block (another function with the await effect) or within scope of a runtime that handles the effect.
But even that is a bit limiting.
> And if that's part of the call stack, why not just make that an explicit function?
This is kind of a meaningless question depending on how you formulate it, because the big thing about things like effects is that the callee both returns more than once and is called more than once - so the notion of a "call stack" is kind of meaningless.
For example if f calls g and g raises E1 and then E2, f can declare a handler for E1 which moves it into a different scope that has a handler for E2. From the perspective of g() there is no function to call to deal with E1 and E2, since it's the responsibility of the caller to determine that.
I think if you wanted to get weird with the control flow like this you might as well make a state machine. All of this seems to be completely missing the reason we even have stack based programs to begin with: they are inherently easier for programmers to reason about.
I think these effects would ultimately lead to a bunch of hard to find bugs, all to replace the functionality of a callback.
† With added asynchronicity.
[1] http://community.schemewiki.org/?call-with-current-continuat...
[2] Some argue call/cc is, in fact, worse than goto: https://okmij.org/ftp/continuations/against-callcc.html