Guide section 5.1 on object destructuring may lead to anti-pattern

This issue is realted to guide section [5.1 Use object destructuring when accessing and using multiple properties of an object](https://github.com/airbnb/javascript/blob/master/README.md#destructuring--object)

Although the section rationale and examples are very clear and logical, IMO when followed unrestrictedly (or naively) it may lead to an anti-pattern with the bad features this very section is trying to avoid in the first place (repetitive code, opportunities for mistakes and unnecessary extra temporary references).

Apparently the anti-pattern arises more clearly when there is a combination of these conditions:
* Accessed object properties have meaningful names and are each only referenced once, thus not requiring local variables.
* There are more than a handful of accessed properties
* The accessed properties are mostly used to create a new object, with or without key/value transformations

Here's an example to illustrate:

```javascript
// bad
function toNewUserType(user) {
const {
id: userId,
status: userStatus,
email,
phone,
encryptedPassword,
firstName,
middleName,
lastName,
jobTitle,
birthDate,
createdAt,
updatedAt,
address,
} = user;

return {
userId,
userStatus,
email,
phone,
encryptedPassword,
jobTitle,
birthDate,
createdAt: toDate(createdAt),
updatedAt: toDate(updatedAt),
address: toNewAddressType(address),
userHash: idToHash(userId),
fullName: getFullName(firstName, middleName, lastName),
};
}

// still bad
function toNewUserType({
id: userId,
status: userStatus,
email,
phone,
encryptedPassword,
firstName,
middleName,
lastName,
jobTitle,
birthDate,
createdAt,
updatedAt,
address,
}) {
return {
userId,
userStatus,
email,
phone,
encryptedPassword,
jobTitle,
birthDate,
createdAt: toDate(createdAt),
updatedAt: toDate(updatedAt),
address: toNewAddressType(address),
userHash: idToHash(userId),
fullName: getFullName(firstName, middleName, lastName),
};
}

// good
function toNewUserType(user) {
return {
userId: user.id,
userStatus: user.status,
email: user.email,
phone: user.phone,
encryptedPassword: user.encryptedPassword,
jobTitle: user.jobTitle,
birthDate: user.birthDate,
createdAt: toDate(user.createdAt),
updatedAt: toDate(user.updatedAt),
address: toNewAddressType(user.address),
userHash: idToHash(user.id),
fullName: getFullName(user.firstName, user.middleName, user.lastName),
};
}
```

If the package owners agree with the problem, I believe we should be able to add some content to warn about this anti-pattern and how to avoid it.

Thanks in advance.

Start with section 5.1, “Use object destructuring when accessing and using multiple properties of an object,” in README.md and compare its guidance with the examples in this issue. Review the proposed anti-pattern cases and add guidance explaining when direct property access may be preferable, with a clear example of the intended rule.】【。}񟟂яда 񟂀񟟂 กรุงเทพมหานครฯ 天天彩票提现? Wait invalid extra? Need ensure only JSON. I accidentally included weird? final content currently has weird after string? Let's craft clean.}==? Need answer. Source final should no weird. Use valid JSON. Ensure research 2 sentences. maybe

Written by the indexing model from the issue text.