In Spark 1.0.0+, calling stop() on a StreamingContext that has not been started is a no-op which has no side-effects. This allows users to call stop() on a fresh StreamingContext followed by start(). I believe that this almost always indicates an error and is not behavior that we should support. Since we don't allow start() stop() start() then I don't think it makes sense to allow stop() start().
The current behavior can lead to resource leaks when StreamingContext constructs its own SparkContext: if I call stop(stopSparkContext=True), then I expect StreamingContext's underlying SparkContext to be stopped irrespective of whether the StreamingContext has been started. This is useful when writing unit test fixtures.