There's no real difference between a lambda and an object full of state, beyond the syntax. Lambdas capture arbitrary state.
When functional programmers talk about state they're referring to mutable state. What you are describing is simply data. Capturing immutable data provided through function arguments does not violate referential transparency. You still get the same result for the same arguments.
Plus, in real software, the results of some functions is often some measurement of some changing real-world thing.
That isn't a function, not in the mathematical sense. In Haskell it would be referred to as an I/O action. In functional programming objects exist which describe "impure" actions, such as sampling a sensor or printing to the console; these objects can be manipulated by pure functions, e.g. combining two actions to make a larger action, or mapping a function over the result, but are only executed (logically speaking) by an impure external interpreter in the language runtime. The program itself is pure, even the parts which evaluate to IO actions—barring abuse of specific constructs like unsafePerformIO. The runtime, inevitably, is not pure, since has the responsibility of interfacing between the pure program and the real world.
 For performance reasons, of course, the compiler actually "inlines" the interpreter, generating impure object code similar to a traditional compiled imperative program. The external interpreter, like the C virtual machine model, is merely an aid for thinking about the code, not a concrete implementation.