You can go too far even with short pipe sequences! For example, I have seen some code that does this:
def foo(list) when list |> is_list() do
which I am not a big fan of! 
Just to clarify, because it is slightly ambiguous, Kernel.- was not made available to be used as a pipe. All of our auto-imported functions are defined in Kernel. In this way it is similar to erlang:'-'(1), except Elixir considers all operators to also be valid identifiers (i.e. they don’t require quotes around them).
Oh fully realise this! Sometimes you need to be able to access all the built-ins as “normal” functions and not as operators, but perhaps not here. 
You yourself already adressed this two sentences later but in my eyes I should do my best to write production-grade code even for my hobby projects. I can stick to ugly and hardly-understandable code until I make something hard [for me] to eventually work but my next session immediately starts with refactoring – which also improves the understanding of any code you refactor anyway.
Indeed, asking yourself if you will understand what you were writing N weeks or months down the line is the right question.
Well to be fair this can be said about any language and any framework/library and feature they have. Don’t even ask me which crazinesses I’ve witnessed in my PHP and Java days – I’ll legitimately be a happier person if somebody wipes them off my brain, it can replenish some long-lost naive optimism that I sometimes desperately need.
Oh yes, there are things in most languages which people misuse. In Elixir many are in love with pipes and some overuse them. Another non-Elixir specific example of things which are often misused are macros. Don’t get me wrong, as an old lisper I love macros, but they are both the road to heaven and the road to hell.
An interesting discussion. I also don’t like Kernel.-(time_elapsed) in a pipe.
I think it is difficult to say which length on a pipe is good an which is bad. Because it depends on the purpose of a pipe and the transformation of the data.
If I have to review the code snippet we had start with I would suggest something like this.
schedule_events(interval - time_elapsed)
@spec schedule_events(int) :: {:ok, ...} | {:error, ...}
def schedule_events(time) when time >= 0 do
...
end
def schedule_events(past), do: {:error, :missing_timemachine}
No pipe and the function takes control of its argument.
It probably would be a good candidate for with construct rather than pipe operator for readability and possibility of adding constraints/error handling/crashing when we want to.
Nowadays I find myself using with more and more and I often start with a pipeline just to refactor it afterwards to more explicit with syntax.
Wow: it’s really interesting to see this discussion. I wrote a whole post on/around this: Erlang, Elixir & RabbitMQ resources - Erlang Solutions Blog
I don’t think it is the length per se which is the problem. I think that when you are transforming data from one type to another it can be help clarity and understanding by naming things using variables.