There is some truth in this, but I don't think it fully expresses Swift's "attitude".
Equatable is not the "best" way to work with value types. Rather, it's a clear, explicit conformance that allows any type to declare that it provides a standard equality behavior. Omitting Equatable conformance, conversely, allows any type to declare that it has no standard equality behavior (a subtlety which Obj-C is unable to express, but desperately needed).
Swift focuses on value types different reasons. The primary one, I'd say, is that a lot of bugs are avoidable if the values being passed around are not mutable when they don't need to be. (In Obj-C, for example, a function might return a pointer to a NSMutableString as a NSString, and other code might mutate this same string behind the scenes, undermining the code that uses the function result. This sort of problem means that good Obj-C code does a lot of object copying to gain "sole ownership" of a particular instance.)
Obj-C's objects-as-value-types did complicate both semantics and code, but it had huge benefits as well. It meant that code had a way of treating pretty much everything as an object, and there are a lot of very useful things built on this, such as KVC, KVO and bindings.
This has already been sort-of answered, but to be explicit, I'd do this:
array.removeAll { $0 === objectToRemove }
This may not be terse enough for you, but I find it short enough, and extremely clear on what basis the removal is conditioned.
Addendum: I was also going to mention that Obj-C's NSArray has both removeObject: and removeObjectIdenticalTo: methods.
The first uses isEqual: (== in Swift) to compare objects, the second uses pointer identity (=== in Swift).
Obj-C has painted itself into a corner where both are needed, but confusion between the two is a source of bugs, even — I would claim — for very experienced Obj-C programmers.