I am going to try to unpack this, since I see several distinct aspects to this issue:
The root cause
Your package uses architecture all. This means it will be referenced in the repository metadata of you published APT repo within the file found at dists/default/all/binary-all/Packages. Since your repo does not contain any packages that are explicitly amd64 and you did not sync an upstream repo that advertises itself as supporting amd64, Pulp has no way of knowing that this repository is intended for amd64 hosts. As a result the release file found in the published Pulp repository (at dists/default/Release) does not list amd64 in its Architectures: field.
Since your hosts are amd64 they will complain about repositories that do not do this, that is the message you are seeing.
Maybe it just works inspite of the message
Have you actually tried to install your package on one of your hosts with the repo configured?
In spite of the fact that your hosts say: N: Skipping acquire of configured file ‘all/binary-amd64/Packages’ (because this file does not exist in the repo), maybe they do still acquire all/binary-all/Packages which does exist and inludes the metadata for your package.
You tried to change your package to amd64 which did not change anything
I am not sure why this does not fix things. If you have a amd64 type package in the repo, then the metadata should list amd64 as a supported architecture and the message should go away. Maybe the hosts are still using outdated metadata try clearing any local APT caches. Otherwise this sounds like a bug.
Possible workarounds
First of all, see “Maybe it just works in spite of the message” above.
One way that should get rid of the message, is to also upload some amd64 architecture specific package to the repo that you verified as “working”. You mentioned http://archive.ubuntu.com/ubuntu/ubuntu/ubuntu/pool/main/v/vim/vim-common_7.4.052-1ubuntu3.1_amd64.deb did the trick. You now have a package you don’t need in your repo, but so long as it does not hurt…
Some other points
The filename should be irrelevant, but official Ubuntu packages with all in their file name, most likely also have all in their metadata, which is relevant.
Outlook
I think we have here an edge case that is either downright broken/buggy or at the very least could be improved.
Since we are transitioning the APT/deb repo support in Katello to use structured APT, we will most likely fix it for structured APT mode only.