Technically yes, to some degree. However, JVM and Dalvik bytecode retains enough information, compared to machine code, to recover the source with a good enough level of quality that you could sometimes modify it and compile it back.

In the context of JVM, obfuscation is an extra step where identifiers are renamed to various kinds of nonsense to make code more compact and supposedly hinder reverse engineering.

Good question, but no. Obfuscation is an additional step you can take to make it harder to turn that executable back into code.

So with obfuscation you can still decompile the binary into source code, but that version of the source code is much less human-readable and it would take more effort for a human to go through and understand it?

Yes. Imagine that a class like "me.grishka.app.something.SomeDescriptiveClassName" gets renamed to "zzq" in the default (root) package. You end up with thousands of classes in there, none have sensible names, and nothing inside them has sensible names either. So you do have to spend extra effort to rename them back to something that makes sense. A good starting point for figuring out what an obfuscated class does is to look for log messages.

Java classes must still have names, and methods and fields must also retain type information for the JVM to work. Inside a JVM, classes and fields are accessed using names, and methods are accessed using name+signature, the signature being of the form "(Ljava/lang/String;II)V", that's a method that takes a string and two ints and returns void.