traffic blocked outside of AT&T

Initially my website was visible to the world but the past 3 weeks it is only visible within AT&T...Does it make sense to anyone that replacing said BGW210 will solve my problem?

No, it won't solve the problem unless you started filtering IP addresses or subnets on your BGW210 or some downstream router on your home network or on the host (web server) itself.  In that case though a factory reset and reconfiguration of your existing BGW210 or downstream router (if you have one) would also solve the problem.

If you are not filtering, then it sounds like this is a problem upstream with AT&T's routers (routing tables) not yours.

What is the IP address or domain name in question?  Comparing traceroutes from within AT&T's network and from without will show where the traffic is being blocked or dropped.

Another thing to try is have you enabled IPv6 on this web server?  Does it have a AAA domain record?  Do you have your BGw210 set to allow incoming unsoliticted IPv6 traffic ("reflexive acl" set off)?  If so, is IPv6 traffic to the server blocked as well?

Yap. I completely agree. AT&T solution was to send a new box, and sure enough, did not solve anything. Last option I can think of is getting a different set of IPs since AT&T doesn't cooperate with the current.

Last option I can think of is getting a different set of IPs since AT&T doesn't cooperate with the current.

If all you are using the static IP addresses for is a web server(s), then I wouldn't bother getting static IPv4 addresses.  AT&T already issues global unicast IPv6 addresses for free to devices behind the AT&T gateway (BGW210 in your case).  Use a non-temporary one of those (if your host/web server has several addresses) to host your website and then use an IPv4-to-IPv6 translating reverse proxy service to provide IPv4 access to your website(s).  You should be using a reverse proxy from a CDN like Cloudflare to host a public website anyway for DDOS protection even if for nothing else, so enabling IPv4-to-IPv6 translation functionality with it is a no-brainer.  Doing this will allow ipv4-only clients/devices to access your IPv6-addressed website.

Thanks.. would not apply to rsync

>>> using a reverse proxy from a CDN.. like Cloudflare <<<< sounds like paying for a workaround whereas if AT&T did their routing correctly I would not having this issue. I was doing fine with static IPv4 69.152.38.233 until 2023.02.14 when looking at httpd (apache) logs and rsync (only exactly 2 sites allowed) at approx 0500 Pacific 69.152.38.233 became out-of-reach of AT&T

sounds like paying for a workaround whereas if AT&T did their routing correctly I would not having this issue.

I am not defending AT&T.  If the problem is a configuration issue with its routers upstream as I surmised, then AT&T should fix it.  My point regarding using a reverse proxy is that you should be using one regardless.  Running an Internet-facing website without one is really asking for trouble.  It's not a question of if you will have bad actors attack your site, but when and how often they do it.  And, since a reverse proxy would also solve an IPv4 routing or access issue, it is a no-brainer.  In addition some CDN's like Cloudflare have a free/no-cost plan which provides basic proxy and DDOS protection services.  So, it's not necessarily a matter of having to pay for something you don't yet realize you need.  You are already paying AT&T for static IPv4 addresses, but that money would be better spent on a good reverse proxy service and on domain registration for your server(s) instead.

I just ran a series of traceroutes from an online service from nine different locations around the world with two in the U.S. plus one I ran locally from my AT&T residential Internet service to 69.152.38.233.  All of the traces dropped after IP address 99.75.21.179 (99-75-21-179.lightspeed.sndgca.sbcglobal.net) which I assume is your BGW210 gateway.  Assuming your website @ 69.152.38.233 was online when I posted this, that means that the route to your web server is correct, but your BGW210 is not forwarding the ICMP traffic to your web server.  That could be due to your firewall settings on the BGW210 being set to block incoming pings to devices on the LAN (behind it).  Of course blocking ICMP traffic to your web server doesn't make it unreachable by a web browser.  But, there may be some other firewall rules on the BGW210 which are blocking web traffic to it.

This basically puts the culprit as your BGW210 gateway assuming that your web server was online when I ran the traceroutes.  I also unsuccessfully tried to connect to the website from a web browser using my AT&T residential Internet service.  If your web server was online at the time, then either the BGW210 configuration or the web server itself is to blame.

My thanks to jdtoo, it had escaped my attention to check again each and every setting on the BGW210. Albeit the question of why on 2023.02.14 outside of my home network / AT&T residential Internet  address 99.75.21.179 :: traffic stopped cold until today 2023.03.08 when on the BGW210 :: Home Network -> Subnets & DHCP -> Allow Inbound Traffic -> On <= was Off