Q:

Why do we pass objects rather than object members to functions? 

I have a method FOO() in class A that takes as its arguments input from data members of class B among other things (let's say they are two floats and one int).  The way I understand this, it is generally better to implement this with something like:
A->FOO1(B, other_data_x)

rather than
A->FOO2(B.member1, B.member2, B.member3, other_data_x). 

I gather one, but not the only, advantage of this is that it leaves the detail of which members of B to access up to FOO1() and so helps hide implementation details. 
But what I wonder about is whether this actually introduces additional coupling between classes A and B. Class A in the former case has to know class B exists (via something like include class_B_header.h), and if the members of B change or are moved to a different class or class B is eliminated altogether, you have to modify A and FOO1() accordingly.  By contrast, in the latter approach, FOO2() doesn't care whether class B exists, in fact all it cares about is that it is supplied with two floats (which in this case consist of B.member1 and B.member2) and an int (B.member3).  There is, to be sure, coupling in the latter example as well, but this coupling is handled by wherever FOO2() gets called or whatever class happens to be calling FOO2(), rather than in the definition of A or B. 
I guess a second part of this question is, is there a good way to decouple A and B further when we want to implement a solution like FOO1()? 

A:

But what I wonder about is whether this actually introduces additional
  coupling between class A and B.

Yes, it does.   A and B are now tightly coupled. 
You seem to be under the impression that it is generally accepted that one should pass objects rather than members of those objects.  I'm not sure how you got this impression, but this is not the case.  Whether you should send an object or members of that object depends entirely on what you're trying to do. 
In some cases it is necessary and desirable to have a tightly coupled dependency between two entities, and in other cases it is not.  If there is a general rule of thumb that applies here, I would say if anything it is the opposite of what you have suggested:

Eliminate dependencies wherever possible, but nowhere else. 

A:

There's not really one that's universally right, and another that's universally wrong.  It's basically a question of which reflects your real intent better (which is impossible to guess with metasyntactic variables). 
For example, if I've written a "read_person_data" function, it should probably take some sort of "person" object as the target for the data it's going to read. 
If, on the other hand, I have a "read two strings and an int" function, it should probably take two strings and an int, even if (for example) I happen to be using it to read a first and last name, and employee number (i.e., at least part of a person's data). 
Two basic points though: first, a function like the former that does something meaningful and logical is usually preferable to one like the latter that's little more than an arbitrary collection of actions that happen to occur together. 
Second, if you have a situation like that, it becomes open to question whether the function in question shouldn't be (at least logically) part of your A instead of being something separate that operates on an A. That's not certain by any means, but you may simply be looking at poor segmentation between the classes in question. 

A:

Welcome to the world of engineering, where everything is a compromise and the right solution depends on how your classes and function are supposed to be used (and what their meaning is supposed to be). 
If foo() is conceptually something whose result depends on a float, an int, and a string, then it is right for it to accept a float, an int, and a string.  Whether these values come from members of a class (could be B, but could also be C or D) it does not matter, because semantically foo() is not defined in terms of B.
On the other hand, if foo() is conceptually something whose result depends on the state of B - for instance, because it realizes an abstraction over that state - then make it accept an object of type B.
Now it is also true that a good programming practice is to let functions accept a small number of arguments if possible, I'd say up to three without exaggeration, so if a function logically works with several values, you may want to group those values in a data structure and pass instances of that data structure to foo().  
Now if you call that data structure B, we're back to the original problem - but with a world of semantic difference! 
Hence, whether or not foo() should accept three values or an instance of B mostly depends on what foo() and B concretely mean in your program, and how they are going to be used - whether their competences and responsibilities are logically coupled or not.