I had my first experience with Jupyter last weekend when I was trying to learn about document clustering with Python. It seems like a cool idea, but in practice ended up being kind of annoying: https://github.com/brandomr/document_cluster/issues/7
Jupyter notebooks are for running ad hoc blocks of code. The biggest advantage of doing so is being able to check the output of each block to make sure the output is expected. This feature in particular makes for a great tool for tutorials. (Example of mine: https://github.com/minimaxir/facebook-page-post-scraper/blob...)
It is definitely not a tool to replace a typical Python workflow.
Jupyter is great for prototyping and playing with ideas, essentially its great it you want persistent data. But after you more or less know what you want and loading the initial dataset isn't a constant annoyance you're usually better off in an IDE or other real programming environment.
I use it to ask a whole bunch of exploratory questions about a dataset then productionize the result in PyCharm (my preference, other ways work great too :)
This is actually my main problem with the whole idea of these "notebooks". They explicitly encourage exactly the kind of ad hoc coding and practises that plague a lot of scientific work. It's nearly impossible to practise good software engineering while inside one of these things. I know the rationale will be that this is for ad-hoc exploration and the code should be rewritten / redesigned when it's moved into an app, but just like all prototype code that has ever been written, that is not what happens.
I would love something that combines this style with support for good software practices. For example, that let's you seamlessly move snippets of code into functions, classes, modules, and then create tests for them. RStudio is actually the closest I have found, which is ironic since as a language R is horrible for encouraging good software practices.
I teach an internal class on python at my office, and the notebook makes it significantly easier to work and play with code. It's a step between a REPL and a file you load and run each time you make a chance. It speeds up the dev/test cycle significantly.
It works really well in a class scenario. A professor can just show a notebook on the screen “live”: walk through it, or even change things and demonstrate the effects. And when finished, the whole thing can be posted as a file for students to download and try themselves.
It is definitely not a tool to replace a typical Python workflow.