Trailing slash in GNU and BSD cp and find commands

What might be a reason that BSD cp and find don't "like" a trailing slash for directory names?

|     |            cp            |            mv            |
|-----|--------------------------|--------------------------|
|     | # to copy dir1/ contents |                          |
|     | cp -a dir1/* dir2/       | # to move dir1/ contents |
| GNU |                          | mv dir1/* dir2/          |
|     | # to copy dir1/ itself   |                          |
|     | cp -a dir1/ dir2/        | # to move dir1/ itself   |
|-----|--------------------------| mv dir1/ dir2/           |
|     | # to copy dir1/ contents | # mv dir1 dir2/ works    |
|     | cp -a dir1/ dir2/        | # same, but I don't      |
| BSD |                          | # consider this syntax   |
|     | # to copy dir1/ itself   | # really correct[^1]     |
|     | cp -a dir dir2/          |                          |

A similar issue with BSD find. It adds a trailing slash after the source path automatically, and so, if, for the sake of consistency\[\^1\], you already added it manually, as in find ./ -type f, the first / will be replaced with // instead. Though it doesn't break anything (at least, until you need to parse it), it looks ugly:

.//file1
.//file2
.//dir1/file3
.//dir2/file4

\[\^1\]: Because the root directory in Unix and Unix-like operating systems is /, I consider a trailing / to be not an excessive or optional but instead a mandatory (though its omission is often forgiven by the tools we use) part of directory names, and so I always refer to them like /usr/bin/ and not /usr/bin (and to refer to their contents, /usr/bin/*).