Its hard to be specific when you are discussing non-standard extensions to a C compiler and the O.P. hasn't specified *which* compiler! However that looks like HiTech PIC C or older XC8 syntax, so I'm going to assume that's whats being used. If you are using something else, ignore this and post the actual compiler make and version you are using.
No, a HiTech PIC C or XC8 variable of bit type does *NOT* have an address in the C sense of address - you cant make a pointer to a bit or have an array of them. However the compiler needs some way of locating which bit in which byte to use when defining them at an absolute address so when applied to a bit, the @ addressing attribute takes a parameter of 8 times the byte address + the bit number within the byte. Its only usable for @ - *NOTHING* else uses bit 'addresses' and they must always evaluate to a compile-time constant expression.
N.B. the bit type is very non-portable. The modern way of declaring that input bit under later HiTech C versions or XC8 would be:
#define BUTTON PORTAbits.RA1
which relies on you having #included the compiler's standard headers. BUTTON is in caps because that's the convention for a name that's a #defined alias. You'd need to make all other instances of it the same case. If you need single bit flag variables, you'd do best to pack them as bitfields in a struct.
XC8 CCI syntax has depreciated bit and @, and that's the default (for C99 compatibility) from XC8 2.0 onwards. You can however enable backwards compatibility, and still use it.